What to start from when building together Raspberry Ubuntu Touch?
-
What counts as success? There are two aspects to consider.
- Getting the Unity8 shell and some core apps running
- Also chosing some "phone" hardware and adding support
Unity8 has yet to be ported to distros beyond Ubuntu, so goal 1 would be easiest on Ubuntu. On the other hand, having it running on Raspbian or as a Snap would generate interest.
Goal 2 will surely need kernel work and is an area that will be problematic to integrate into Ubuntu Core & snapd.
-
This post is deleted! -
This post is deleted! -
This post is deleted! -
I don't know if this is still a thing.
I find this:DEV LineageOS 14.1 (Android 7.1.2) for Raspberry PI 3 B
so probably we can try to use the normal porting guidelines
In the future, for when halium will be able to handle Android8, is already available this:
DEV LineageOS 15.1 (Android 8.1.0) for Raspberry Pi 3 B and B+both of them are done by Konsta developer
sadly both of the Raspberry Pi boards have only 1GB RAM
-
Hi, I can help put some images together if UBports are still interested in the pi. The pi 3 is capable of armhf and arm64 so either is possible. I've quite a bit of experience at building images, an example is the unofficial xubuntu installers I made for the pi 2 + 3: https://ubuntu-mate.community/t/aarch64-on-raspberry-pi-2-rev-1-2-3b-3b/16853 . I've tried kwin under wayland on the pi3 and performance was good.
I don't know a lot about Ubuntu Touch. From my brief reading around it shouldn't be too hard to put together a 18.04 image with Unity 8. You'll have to guide me on what Ubuntu Touch brings on top of Unity, and if that can be installed outside of a phone/Android. A 16.04 image is also possible, but to get the latest vc4 graphics 18.04 would be better.
Are there any amd64 images of Ubuntu Touch/Unity 8? If not, is this something that UBports are also interested in?
-
Hi @adams, what I can tell you is that UBports is definitely interested in getting a working image for the Raspberry Pi; prove of that is we have a telegram chat reserved to gather people to make this possible (unfortunately I'm not able to give you the link right now, i will do later if you are any interested). The captain of this chat is @jonius and probably he can give you some insight and more technical explanation which I'm afraid I am not able to give you, and maybe agree what's the direction to be taken in order to turn this into a reality.
-
@matteo the group in Telegram is https://t.me/UBports_pi but I don't know if there's another in Matrix too
-
@adams Would not the 4.15 kernel and newer mesa stack provided by Ubuntu 16.04.5 provide the newer graphics drivers you mentioned from 18.04?
-
Also, I think a really good first step here would be to identify which components of the stack rely on using android properties for storing certain option values, and reporting issues for those. This should be one of the easier things to migrate away from, to make things more consistent with the x86 unity8 stack builds.
Next we should identify components which have a hard dependency on hybris, and document those in issues as well. This will be much harder to fix, as we'd need to re-architect things a bit, so that hybris is not the only method of interacting with the system. Ideally, this would be done by making hybris a runtime loadable dependency, via an abstraction, so we could avoid shipping hybris entirely on device that don't need it. However, it will be much more difficult to do that, rather than to keep shipping it, but fixing code to handle certain failures more gracefully and to access hardware more directly when running on top of more standard Linux devices.
-
@adams Ubuntu Touch is a bit more than just Ubuntu + Unity8. Until now Ubuntu Touch has only be build for Android phones, so the partition layout is different (https://forums.ubports.com/topic/1296/partition-layout). The root file system is read-only, there is app confinement, we access the hardware via libhybris (to be compatible with Android drivers) and so on (there are 400 UBports repos on github https://github.com/ubports).
In my opinion, as a first step it would already be nice to have raspy images with Ubuntu+Unity8 running for testing. Next step would probably be what Rodney says.
-
Thanks for the replies.
There is a pi usable 4.15 kernel for arm64, but currently the generic armhf doesn't work on the pi. The only armhf kernel is the Linux-raspi2 kernels https://launchpad.net/ubuntu/+source/linux-raspi2. So if 16.04 is the best for UBports, then arm64 is the easiest to go for without recompiling a kernel.
I'm not sure what the status is of Android on the pi (when I say pi I really mean the pi 2 or 3B/3B+) or what graphics drivers it uses. I haven't yet tried any of the Android builds. A recent-ish article that mentions the pi is this https://archive.fosdem.org/2018/interviews/robert-foss/ .
Hardware accelerated video decode will soon be available via v4l2 video codecs.
Has anybody just tried running the unity 8 installer script https://raw.githubusercontent.com/ubports/unity8-desktop-install-tools/master/install.sh ?
-
I ran the unity install script in 18.04 armhf. Unfortunately, I had the bionic-backports repo enabled and I think something there upset it. Removing the repo and reinstalling mir got me into the desktop, but things were quite broken. Think I'll start a fresh with 16.04 arm64.
-
@adams Can you be more specific about what you mean by "broken" here? The unity8-as-a-traditional-environment setup is not working well, especially on 18.04, in general.
-
I couldn't login to the session. Black screen for a few seconds, then it would kick me back into lightdm. Tried that several times. I removed/reinstalled mir, that seemed to do something. I was able to login, although it seems to always take me two attempts, so not sure if it did anything in the end. No keyboard entry in Unity8 (can't even switch to a tty). Window controls don't work - xwayland problem maybe?
-
@adams OK. Yes, it always takes two attempts to log in to the Unity 8 session on 18.04. This is the same on x86. Xwayland doesn't work, so there are no visible problems directly related to that. Window controls have stopped working for me as well, in my testing VM. I'm not sure why that is yet. Keyboard entry works fine from an external keyboard (but there are some very odd focus issues). The OSK does not work yet though. I've fixed a couple things with it, but I've not been able to get it to appear yet.
-
Apologies for resurecting an old thread, but I was just wondering if anyone had made any headway with getting UT on a Pi?