Or just open and edit the last line, changing qxdisplay to qxcompositor. Then the GUI app can start X sessions too.

P.S. Of course, first qxcompositor should be installed from

Fresh port (not ready yet) - Samsung Galaxy S4 (i9505) - SFOS 4.4 and LXC with Debian Sid:

On SFOS 4.4 I've got some problems. I mentioned them on the first page and also how to workaround them.

Thanks - going to check it out. .. Wonder if you have any idea about this - I had my Containers app working fine, with 2 containers, and able to start/stop and attach, etc., but then I was experimenting with some other things related to Python3 and Cairo, and now there's no gui. The containers app opens and is just a blank screen. The containers are still there, and work fine, but the app is tripped up by somethung I did. I tried undoing/uninstalling changes, but not sure where it happened... Outpu when running the app is:

I guess something to do with dbus daemon, but can't figure out what to do about it. ..
Thanks

UPDATE - nvm- fixed with reinstall dbus-python... Thanks

@edp17 - I have successfully gotten desktop env with Debian Sid and with Devuan. I've tried many others, but haven't goten any others to work yet, (error somerhing like "desktop not supported for distro..."). Do you know if any way to get desktop with any others?

So far I only tried Debian Sid.
I think the issue you described is down to the Xwayland binary. Xwayland should be patched for making it work under SFOS. The patching is done automatically when the script is installing the distro and it requires the source of Xorg. About two years ago when I installed Sid first, the script was able to download the Xorg source and then patch and compile Xwayland.
However, the last time when I installed everything from scratch, the script wasn't able to do that. (This is the issue I mentioned on the first page. I don't think this is connected to sfos version, more likely it is because the source of xorg cannot be found/downloaded.)

Probably when you install other distros, they are installing the default Xwayland binary and that's why you are getting that message.
Have you tried to copy the Xwayland binary from a working distro to a new one? (It is located in /home/.lxc/<container_name>/opt/bin/)

After more than two years of use of my container, I'm trying to get harbour-containers to work on the Pro1x and its SFOS port. I was stuck in 3.3 for a long time on my Pro1 (laziness because the upgrade implied reflashing due to encryption) and already had a working container, so now is the first time I face the same issues that others have faced here in the last months.

Some notes I took along the road:

- There are no aarch64 builds on the repository, but…
- There are aarch64 builds here for harbour-containers, qxdisplay and even qxcompositor, so we can choose (this will need editing /usr/share/harbour-containers/scripts/host/new_display.sh of course).
- The instructions in harbour-containers' README don't mention xz ad a dependency; presumably it was pre-installed on Pro1, but is missing on Pro1x. Just run devel-su zypper install xz.
- From there, lxc-create -t sfos-download -n <container-name> works, and so does container creation from the harbour-containers GUI (at least the aarch64 build from the above mirror, which includes HengYe's PR to disable Sailjail).
- However, while checking "Setup desktop" in the GUI looks encouraging in the beginning, it quickly breaks bad with a lot of errors showing up, and ultimately a (reproducible) crash of the terminal where it is being run. I think I noticed a lot of red text around an Xwayland step, and since Xwayland is supposed to be built from source to apply some patches, I thought the sources were not reachable anymore. This is when I ended up here and noticed that edp17 already noticed the same long ago; thanks!
- I therefore downloaded the latest Xwayland-….bin file as instructed in the FP with wget https://github.com/sailfish-containe....libc-2.29.bin followed by mv Xwayland.aarch64.libc-2.29.bin /home/.lxc/<container-name>/opt/bin/Xwayland && chmod +x /home/lxc/<container-name>/opt/bin/Xwayland.
- But this was not the only issue I got with the setup_desktop.sh script. I got a lot of failures to resolve deb.debian.org, which I could solve with echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf > /dev/null ran from inside the container (devel-su lxc-attach -n <container-name>). The issue may or may not be related to this, I don't know yet. I wonder if this wouldn't have solved the Xwayland download in the first place.
- From within the container still, I then ran /mnt/guest/./setup_desktop.sh as root again to restart the X desktop setup.
- Then, to my great surprise, the "Xsession" button inside the harbour-container's GUI worked!



Currently I'm using qxcompositor, but I suspect qxdisplay would work as well. I don't use portrait rotation given the device I use, but as far as I remember, Elros34 merged the qxdisplay patches into qxcompositor, so both should now support the same -o flag, and therefore hopefully work equally well for switching orientation from the corresponding button in harbour-containers' GUI.

Since I was having issues initially, I made a nemo symlink with sudo ln -s /home/defaultuser /home/nemo before the steps above, so I cannot tell if all this would have worked without the symlink. I doubt it since, as far as I remember, harbour-containers still doesn't support user names other than nemo. I had a PR pending for that but it's not merged and I'm not even sure it works.

Anyway, glad to see Debian on the Pro1x this early!

Dynamic orientation works in LXC even with a tiling WM, thanks to qxcompositor (we were using qxdisplay with harbour-containers since 2020 because at the time qxcompositor didn't support portrait, but qxdisplay doesn't support dynamic changes so the update qxcompositor is now superior):

https://youtu.be/wq3-rhB4pwA



Useful mostly for other devices, but even on Pro1 it can be cool when just consuming content without the keyboard. So there's a real benefit in editing /usr/share/harbour-containers/scripts/host/new_display.sh to replace "qxdisplay" with "qxcompositor", and installing qxcompositor from the URL in the above message.

Thanks for sharing this!
The URL of sailfish-container under the video gives 404 not found. (Because there is an extra ")" at the end.)
If somebody interested here is the link to the new qxcompositor for armv7hl (sfos 4.4.0.64).

https://github.com/sailfish-containe...our-containers

My PR to harbour-containers has been merged, it should now work much better than the upstream one that was using qxdisplay and, most of all, could no longer configure X in new containers properly.

Instructions have been simplified, with just 3 packages to install from one single place (and hopefully from Chum soon), better default settings for X scaling and Onboard vkb, and most of all without the need to tweak things manually to debug container creation.

- 3 packages to install from a single OBS repo,
- no need to manually debug things when creating a debian-based container or work around the Xwayland compilation,
- dynamic rotation,
- sane default settings for X scaling and Onboard (for non-hwkb devices),
- simplified instructions,
- new icon :O,
- no polkit prompts for nothing after boot.

Unfortunately, only armv7hl and aarch64 are supported. We used to manually patch sources of Xwayland and build from that, which broke when Xwayland dropped support for autotools. I fixed that issue and the compilation step in the installation script now would work, but it appears that Xwayland sources no longer support a protocol that we need for SailfishOS, so I just plain and simple disabled that whole part of the installation (it's still there in `/usr/share/harbour-containers/scripts/guest/setups/debian.sh`, but commented out, if some want to play with it). That means we're back to just fetching binaries that were pre-built in 2020, and we only have armv7hl and aarch64 available sadly.

I'll make another post if some important changes are made, or if this makes it to the Chum repository for easier installation.

X looks like this at first boot now, which should definitely be a lot more usable (but I still advise to configure things to set up as many keybindings as possible to manipulate the WM):