Desktop Linux on Pro1 without sacrificing telephony: LXC containers in SailfishOS (video)

[matf-kabouik 414]

 

LXC is such a good combination with the Pro¹ that it might be worth a video on the official forum, even though I'm not very active here:

- LBRY for good connections (big file): https://open.lbry.com/@Kab:7/LXC_sailfishos_Pro1:b?r=BZ8k2XPpJvbZhRttC15UQs34pYd2SS97

- Youtube for slower connections: https://youtu.be/-dgD5jci8Dk

 

 

DESCRIPTION
Sorry for the annoying accent. This is an overview of full desktop Linux distributions running as LXC containers in SailfishOS, on a F(x)tec Pro1 qwerty slider phone. If not interested in Sailfish itself, jump to 06'23" for Kali XFCE (fresh install) or 08'40" for Debian i3-gaps (configured install).

I am not affiliated to SailfishOS or F(x)tec, and am merely a community member using sailfish-containers since a few months. This application is being developed by r3vn (https://github.com/sailfish-containers) and is inspired by previous work by elros34 and Preflex on chroot solutions
and Xwayland.

Battery use is similar with and without containers running, one can go through the day with a full charge and light to normal use. The Pro¹ does not have a bleeding edge SOC, but the performance is good enough for what I use it for, and using this SOC may actually be an advantage for overall Linux support (drivers, mainlining task).

It is possible to use the us-intl layout and deadkeys on the hardware keyboard, this is how I use it. There is also support for external keyboard and mouse, meaning we're only missing hw-decoding and, most importantly video-out through the USB-C port, for ultimate "Convergence" where we'd get a full desktop experience and not a mobile OS with an external display. Hopefully someone will find a way to make video-out work on Sailfish so we can get the perfect Linux travel companion.

Content:
[00:00] Introduction to Sailfish on the Pro¹ 
[00:44] Sailfish multitasking view 
[01:11] Hardware keyboard support in SailfishOS 
[02:31] Application to install/manage Linux containers 
[04:14] Foreword on the known limitations 
[05:43] Kali XFCE (fresh install) 
[08:40] Debian i3-gaps (configured install) 
[08:58] Darktable 
[09:17] Short demo of i3wm for those not familiar with tiling WMs 
[11:23] Firefox desktop 
[12:10] Quick peek at the similarity of my desktop environments on a full size computer and on the smartphone 
[12:49] Keybindings in Firefox 
[13:25] Video playback performance and multitasking 
[14:28] Document editing with Libreoffice 
[16:12] Multitasking example 
[16:45] Gimp 
[17:30] nnn terminal file manager and Nautilus 
[18:41] Using Onboard virtual keyboard on touch-only devices 
[20:47] Conclusion and some words about device compatibility, performance and battery use 

Links:
sailfish-containers repository, https://github.com/sailfish-containers

Edited November 13, 2020 by matf

[claude0001 1,341]

I had seen this post already quite some time ago, but did not have time to comment up to now (or was too lazy ...).

Thanks for sharing this. Your set-up looks quite impressive. I use my Pro1 in a similar way, but -- for now -- using LineageOS as the basis (see this post). I do have a few questions, that you may or may not be able to answer:

* As long as all alternative OS'es (Lineage, Sailfish, UbuntuTouch, ...) use the same original Linux kernel from stock Android 9 and its (closed-source) drivers, we will never get things like hardware-accelerated graphics in a "desktop" Linux install. So, do you actually think your Sailfish setup is superior in terms of "hardware-support" to all the CHROOT/PROOT solutions for using desktop-Linux on Android? If not, what other advantages do you see?

* In your set-up, you seem to be using the touchscreen as a "direct input" interface. The standard way of using a (desktop) Linux-chroot on Android is to access an X-Session running in the chroot via a remote desktop (RDP or VNC) client. This is quite convenient, as most of those offer the possibility to emulate a touchpad, as well as several mouse buttons. Also, many clients allow gesture-based zooming of the Linux-session which is often useful given the small screen size. Is this possible using your XWayland solution on Sailfish?

* In Android, the security model can be nuisance in this kind of use case, as it prevents fully transparent mounting of Android filesystems in the Linux desktop environment at least for its "sacred" partitions (as far as I understand). How is it on Sailfish? Can you mount any filesystem of the parent OS in the container so that it is writable (for root at least)?

Edited December 3, 2020 by claude0001

[Raksura 270]

11 hours ago, claude0001 said:

* As long as all alternative OS'es (Lineage, Sailfish, UbuntuTouch, ...) use the same original Linux kernel from stock Android 9 and its (closed-source) drivers, we will never get things like hardware-accelerated graphics in a "desktop" Linux install.

Are you sure about that? Hardware acceleration seems to be working on both SailfishOS and Ubuntu Touch. From what I gather, the main issue is the Wayland protocol interfaces not being up to date (SailfishOS, but also sometimes with Ubuntu Touch), not proposing the standard interfaces (SailfishOS), or not quite yet featuring all the stuff they need for hardware acceleration but this lack is being worked on (Ubuntu Touch). Applications ported to these systems are modified to match such restrictions (use Mir on UT until Wayland support is fully there; use the peculiar Wayland interfaces on SFOS) and thus benefit from hardware acceleration. Once the Wayland interfaces get updated, I assume porting applications so that they support hardware acceleration will require little to no work at all.

Edited December 4, 2020 by Raksura

[claude0001 1,341]

3 hours ago, Raksura said:

[...] Hardware acceleration seems to be working on both SailfishOS and Ubuntu Touch.

[...] Applications ported to these systems are modified to match such restrictions [...]

[...] Once the Wayland interfaces get updated, I assume porting applications so that they support hardware acceleration will require little to no work at all.

I was talking specifically about "desktop" Linux distributions (as is @matf in his original post). In trying to be optimistic, I believe you actually illustrate quite well why Android hardware support on desktop Linux will not happen anytime soon. 🙂

Yes, it is possible to use Wayland (and, still, Mir) with libhybris to provide a hardware acclerated display and window manager on an Android device. However, that is not enough.

At the end of the day, Wayland just paints ("composes") windows on the screen. Having a hardware-accelerated window compositor does not magically enable hardware acceleration for the client programs running inside its windows. On standard (i.e. desktop) GNU/Linux systems, client programs rely on things like DRI/DRM (for accelerated OpenGL rendering) and VAAPI/VDPAU (for video decoding). As the Android kernel does not contain driver modules to support those standard interfaces, clients fall back to CPU rendering. Whether the resulting bitmaps are then handed over to X, Wayland or Mir for display is of no importance here. E.g. desktop apps running on Libertine in UbuntuTouch have no hardware acceleration for precisely those reasons.

For distribution-wide hardware acceleration on a closed-source Android basis (like the Pro1's), all relevant programs need to be ported in a way to use libhybris instead of the standard GNU/Linux interfaces. That is of course possible in principle and it is essentially what SailfishOS and UT are doing for their "native" apps (as far as I understand). But, again, my concern is not about phone/tablet OS's.

It seems that for desktop Linux distributions, there is (understandably) little interest in libhybris (read e.g. this discussion on Debian).

I admit that I am not really an expert on all of this, and I might be too pessimistic altogether. But hey, then life is full of positive surprises!         

Edited December 4, 2020 by claude0001

[Raksura 270]

I am also far from being expert on this, so it is entirely possible that I misinterpreted the following conversation:

Quote

Me:
I'm playing around with a prefixed install so that I can compile stuff and have up-to-date software. Learning about how things works as I go. I'm sad to see that even with its latest version, Weston does not have hardware acceleration (I haven't compiled other Wayland applications yet, but I assume they will have similar limitations). From the Wiki page for Wayland, I gather Weston properly interfaces with Wayland, but there is an issue with the EGL interface. I assume (I don't see any error message, so it's kind of a blind guess) the root of the issue is that this interface relies on a library that should provide/use the drivers for the graphics and in my case (a Pro1 phone), these drivers are actually provided by libhybris and Weston doesn't interface with it. Is this correct? Would this require special bindings, or can libhybris be selected as user mode graphics drivers in some way that is transparent to Weston?

TheKit:
currently Mir is missing Wayland EGL buffers integration on Android platform. You can look through the logs here around November 19th
it's not impossible to fix and the code is mostly there, but not integrated and there are some bits that need to be debugged

I took it to mean that once EGL buffers are properly integrated on the Android platform, hardware acceleration will become available to standard Wayland applications.

[claude0001 1,341]

4 hours ago, Raksura said:

I took it to mean that once EGL buffers are properly integrated on the Android platform, hardware acceleration will become available to standard Wayland applications.

That discussion you quote (if I understand it right) is about the hardware-acceleration in the compositor itself, not about client applications.

I believe you have a misconception about what Wayland does and doesn't.

Wayland does not provide a rendering API, i.e. it does not render stuff "on behalf" of its clients. All it does is paint ready-made bitmaps to the screen that the applications provide it with. How the apps do their rendering is completely up to them. As a consequence, also making use (or not) of hardware-acceleration during rendering depends entirely on the client apps.

This may seem like a primitive approach at first. However, that is the very design goal of Wayland: reduce the display manager to the minimally-required functionality to make it efficient and secure.

X11 provided its own rendering APIs for graphics and text and tons of other high level functions that made it powerful in its time, but also complex, inefficient and insecure. Moreover, nowadays all those X11-APIs have become practically useless, as programs prefer to use specialised (and hopefully hardware-accelerated) libraries for their rendering anyway, simply sending over the resulting bitmaps to X. Wayland essentially adopts this de-facto standard procedure as the "official" way to do graphics in Linux, and supports X11-style drawing APIs only via an (optional!) X-server that runs ontop of Wayland, like any other app (XWayland).

Do not worry though, your misunderstanding seems to be so widespread that it is in the Wayland FAQ:

Quote

What is the drawing API?

"Whatever you want it to be, honey". Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer. When the client is done, it informs the Wayland server of the new contents. The current test clients use either Cairo software rendering, Cairo on OpenGL or hardware-accelerated OpenGL directly. Additionally, media frameworks can share their buffers directly with the server. As long as you have a userspace driver library that will let you render into a shareable buffer, you're good to go.

   

Edited December 4, 2020 by claude0001

[Raksura 270]

Alright, that's not quite the point where I think I'm mistaken. I do see quite clearly that there is a difference between the Wayland interfaces and EGL.

What I don't understand is (and that was my question in the quoted discussion, hence my confusion if this is indeed not what the reply is about): the link between client and the user mode graphics drivers, is there a defined EGL API that allows replacing one user mode graphics drivers with another in a way that is transparent for the client, or does the client have to be compiled with an API that is only valid for a specific user mode graphics drivers? I took the reply to mean that there is a standard API, but that part of it (concerning the framebuffers) is currently missing and that's why it isn't working. Now I see the answer might not be addressing my question.

Edited December 4, 2020 by Raksura

[claude0001 1,341]

As far as I understand, EGL is used for sharing the pixmaps between drivers, client-apps, and Wayland. It has nothing to do with rendering itself. Which is done either by the clients themselves or by some libraries they load.

In the example of your picture: A (3D) "game engine" renders its content using Mesa3D via OpenGL function calls. Mesa makes bitmaps and shares them with Wayland to display.

Now the problem with closed-source Android hardware is that "DRM" and "libDRM" are missing. Hence Mesa3D has to fall back to software rendering.

Edited December 4, 2020 by claude0001

[Raksura 270]

I thought libhybris was a replacement for (or at least part of) Mesa 3D so it would be compatible with the Android kernel. I am failing to find a clear picture of what the figure I showed before looks like in the Pro1's version of UT or SFOS. 🤔

Edit:
I'm too tired to read it tonight, but I assume I'm not the only one getting a rather brutal introduction to all of this for the first time, so here's a website that looks like it explains it all: https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=53608808

Edited December 4, 2020 by Raksura

[claude0001 1,341]

1 hour ago, Raksura said:

I thought libhybris was a replacement for (or at least part of) Mesa 3D so it would be compatible with the Android kernel.

Yes, I believe libhybris-based systems do not contain Mesa at all (but I might be wrong). I think via libhybris programs can directly use the Android rendering libraries via EGL (not OpenGL though). Note that libhybris is for much more than just graphics.

I totally agree, that by using libhybris as a workaround one can build a GNU/Linux distribution (the "GNU" is actually the major difference) ontop of an Android kernel (with closed-source drivers). SFOS and UT demonstrate that this is possible.

All I say is: this does not help people (like me and @matf) who want to (additionally) run a desktop-Linux distribution on their phones, as those do not use libhybris but a traditional GNU/Linux graphics stack. And the latter -- understandably -- expects the traditional GNU/Linux kernel interfaces to be present in order to do HW acceleration (and they aren't).

Edited December 4, 2020 by claude0001

[matf-kabouik 414]

On 12/3/2020 at 7:27 PM, claude0001 said:

I had seen this post already quite some time ago, but did not have time to comment up to now (or was too lazy ...).

Thanks for sharing this. Your set-up looks quite impressive. I use my Pro1 in a similar way, but -- for now -- using LineageOS as the basis (see this post). I do have a few questions, that you may or may not be able to answer:

* As long as all alternative OS'es (Lineage, Sailfish, UbuntuTouch, ...) use the same original Linux kernel from stock Android 9 and its (closed-source) drivers, we will never get things like hardware-accelerated graphics in a "desktop" Linux install. So, do you actually think your Sailfish setup is superior in terms of "hardware-support" to all the CHROOT/PROOT solutions for using desktop-Linux on Android? If not, what other advantages do you see?

* In your set-up, you seem to be using the touchscreen as a "direct input" interface. The standard way of using a (desktop) Linux-chroot on Android is to access an X-Session running in the chroot via a remote desktop (RDP or VNC) client. This is quite convenient, as most of those offer the possibility to emulate a touchpad, as well as several mouse buttons. Also, many clients allow gesture-based zooming of the Linux-session which is often useful given the small screen size. Is this possible using your XWayland solution on Sailfish?

* In Android, the security model can be nuisance in this kind of use case, as it prevents fully transparent mounting of Android filesystems in the Linux desktop environment at least for its "sacred" partitions (as far as I understand). How is it on Sailfish? Can you mount any filesystem of the parent OS in the container so that it is writable (for root at least)?

Thanks for sharing your setup too, it looks very interesting and, being running in Android, it undoubtedly can be used by many more people than any Sailfish solution! I'm very happy to hear about users using their device as a desktop UMPC.

1. You two know much more than I do about hardware acceleration and how it works under the hood, to me this is just like trying to understand those green symbols falling down in the matrix, so I won't try to reply accurately to that question. All I can say is the developer of sailfish-containers told me that, theoretically, HW acceleration in LXC could be solved by adding hybris-mobian repository, installing libhybris, and patching wlroots. Containers could then run in Wayland instead of XWayland/Qxdisplay, but this hasn't been tested as far as I know. And who knows how much work would "patching wlroots" be. As for whether LXC is superior to chroot or not, I honestly don't have an educated answer, but I always heard that chroots has a few more limitations, like systemd or the like.

2. I don't think this is possible using the XWayland solution in Sailfish. But it may be possible to use remote desktop solutions too. I know it is possible to use Xephyr/Xnest too, and that the implementation is a bit different. I try that quickly when I wanted to get a software cursor rendered on the screen (which is now fixed in XWayland), and I know it also offered more possibilities to manipulate X settings, like xmodmap (which has no effect in XWayland), although there were different limitations for touch use which made me stick to XWayland. XWayland is definitely suboptimal and merely a way to deal with the Wayland limitations in SailfishOS that Raksura mentionned. It would be interesting indeed to investigate remote desktop solutions as long as the performance and security remains the same, especially if they offer better support for right clicks.

3. That here is a significant advantage of the implementation of LXC containers in SailfishOS. I *believe* you can mount any folder you want, and you will have write permissions if you want to. I only mount my Sailfish $HOME and my SD card.

Edited December 4, 2020 by matf

[claude0001 1,341]

4 hours ago, matf said:

[...]

It would be interesting indeed to investigate remote desktop solutions as long as the performance and security remains the same, especially if they offer better support for right clicks.

[...]

3. That here is a significant advantage of the implementation of LXC containers in SailfishOS. I *believe* you can mount any folder you want, and you will have write permissions if you want to. I only mount my Sailfish $HOME and my SD card.

Most remote desktop solutions (on Android) can emulate right click by two-finger tapping the screen. Some can even do middle click, though my MS RD8 can´t. Security should not be an issue as you can limit access to localhost only in TigerVNC or XRDP. If needed, one can then still access the device remotely via SSH tunneling. Performance is worse than in your solution as the remoting layer adds extra overhead.

Mounting my "home" in Android (i.e. /storage/emulated/0) is precisely what is working only sort-of in my chroot. Effectively, I can only read data from there, but not write there, even though the filesystem is mounted rw in the chroot, and even if I try to write as root. I assume some higher-level Android security layer stands in my way here. I do have full write access to a separate data partition on my SD card, that I can thus use for data that should be read/writable from both systems. 

As for HW accel: For the reasons I discussed with @Raksura, I still fail to see how having an accelerated Wayland compositor (the patched wlroots) would automatically give you hardware acceleration in the client apps, as I think that is completely independent of Wayland. But as I say, I am no expert on this. Just a long-time (desktop) Linux user whom this (otherwise marvelous) Pro1 with its proprietary kernel blobs reminded of the value of (truly) open-source software ... 

Edited December 5, 2020 by claude0001

[matf-kabouik 414]

Thanks for the details. I can confirm I have write permissions on my host's $HOME with no issue, and I think I could also mount the host's / and write there. It is very convenient for me, even though I also kept a separate guest's $HOME for things I want to keep separated.

Edited December 6, 2020 by matf

[claude0001 1,341]

On 12/6/2020 at 11:40 AM, matf said:

[...] I can confirm I have write permissions on my host's $HOME with no issue, and I think I could also mount the host's / and write there. [...]

Thanks to @Linkandzelda's support, I found the solution to my write-access problem as documented in this thread.

In short: In Android (and LineageOS) write access to partitions of the internal storage (not including SD cards, apparently) is protected by a kernel-key. While a chroot environment normally preserves those keys, they are explicitly dropped (for safety reasons) in many Linux distributions when users log on remotely (e.g. via SSH). @Linkandzelda have posted a very informative how-to [external] on their own Linux-Chroot solution that (among others) discusses that problem, which -- once understood -- is actually trivial to work-around.

Edited December 14, 2020 by claude0001