Full linux distros on Sailfish OS - Page 19 - maemo.org

spoofykid | # 181 | 2021-05-28, 03:27 | Report

Originally Posted by levone1 View Post

For the errors about .../usr/share/themes..., you could try

Code:

devel-su pkcon install --allow-reinstall -y sailfish-content-graphics-default-z1.0-base sailfish-content-graphics-default-z1.25-base sailfish-content-graphics-default-z1.5-base sailfish-content-graphics-default-z1.75-base sailfish-content-graphics-default-z2.0-base sailfish-content-graphics-closed-z1.0 sailfish-content-graphics-closed-z1.25 sailfish-content-graphics-closed-z1.5 sailfish-content-graphics-closed-z1.75 sailfish-content-graphics-closed-z2.0

I don't know why it's looking for a qxdisplay desktop file in .../applications. I don't have that ...

Thanks. What's funny is that I already had installed them to get a lower pixel ratio on my screen. They're located in '/usr/share/themes/sailfish-default/meegotouch/...' rather than the ...themes/Jolla... folder. I reset it to standard pixel ratio, and it got rid of those errors, but nothing else got fixed. The qxdisplay.desktop part is still there and seems odd to me - I don't have that file anywhere either.

The Following 2 Users Say Thank You to spoofykid For This Useful Post:
juiceme, mosen

Kabouik | # 182 | 2021-05-28, 14:44 | Report

Originally Posted by Mir57 View Post

It is the script you provided in the first post, used after installing qxcompositor. Did not try mouse yet, did not all of the additional configuration you provided in this recent link.

I'm not the OP!

Originally Posted by

This is what actually holds me from using it as a normal device... As was previously stated, it also breaks any audio in Sailfish OS meanwhile.

Someone mentioned on Github that it breaks sound in SFOS too, but that really is not my case. Have you tried installing pactl? I don't know if this is device-related, or depends on what I configured in my container. Do other Pro1 owners observe sound broken in SFOS once LXC is running, and do they have sound in their LXC container?

Originally Posted by

How could I do this test? Do you have any guide, how to launch xev and see the output?

This is a real rabbit hole but you can start by just installing xev with "sudo apt install xev", then execute xev in terminal, focus the white window, and type on keys. You'll see some (very) verbose output in the terminal. There are xev alternatives that might be a little less verbose or show different information. From there, since I haven't found a solution, I can't really give any instructions, but tools that might allow customizing how keys are handled in LXC include setxkbmap (which operates on xkb layouts), xmodmap (which I think is ignored in LXC due to the fact that we use Xwayland and not just X), kmonad (which I could compile successfully, but couldn't make it read my /dev/input/by-path/keyboard-kbd that I manually mounted in my /var/lib/lxc/debian-sid/config; probably a permission issue).

The Following User Says Thank You to Kabouik For This Useful Post:
juiceme

Kabouik | # 183 | 2021-05-28, 15:15 | Report

I have no idea where the qxdisplay.desktop error comes from, I can't see a qxdisplay.desktop file being called anywhere in the lxc-templates or harbour-containers source files. I suspect it's some other UNIX tool getting in the way somewhere and automatically expecting a desktop file?

Was the container started with the LXC-attach button when you ran the following command?

Code:

/usr/bin/qxdisplay -o landscape --wayland-socket-name "../../display/wayland-container-0

Can you try that one instead where I change the display?

Code:

qxdisplay -o landscape -d ../../display/wayland-container-1

In case you haven't, you should start the container first, attach to it using LXC-attach, and then in a different terminal window, as defaultuser, use that above command.

If your containers are not configured yet, I would indeed start fresh after destroying them and creating a new Debian Sid container. Sometimes things can break with Debian Sid because packages change fast and this version is not made to be stable (at some point the Xwayland compilation was broken for instance). However we tested a few days ago with Mosen on Pro1 and he could install Debian Sid (from CLI only using the instruction in the lxc-templates wiki for now, still issues with creating containers from GUI) and then setup the X desktop using the harbour-containers button at the bottm, and then start X with the above command.

I updated the daemon.py fork, be sure to use the latest version before next attempts.

The Following 3 Users Say Thank You to Kabouik For This Useful Post:
juiceme, mosen, spoofykid

spoofykid | # 184 | 2021-05-29, 10:15 | Report

Originally Posted by Kabouik View Post

I have no idea where the qxdisplay.desktop error comes from, I can't see a qxdisplay.desktop file being called anywhere in the lxc-templates or harbour-containers source files. I suspect it's some other UNIX tool getting in the way somewhere and automatically expecting a desktop file?

Was the container started with the LXC-attach button when you ran the following command?

Code:

/usr/bin/qxdisplay -o landscape --wayland-socket-name "../../display/wayland-container-0

Can you try that one instead where I change the display?

Code:

qxdisplay -o landscape -d ../../display/wayland-container-1

In case you haven't, you should start the container first, attach to it using LXC-attach, and then in a different terminal window, as defaultuser, use that above command.

....

I'm not really sure what happened but I got it going - Kali and Debian desktops opened. I placed in your daemon.py and debian.sh files, and then Iinstalled everything through GUI.
What was probably going wrong was I was running the below code as root - as when you select 'attach' in the Container GUI, and then open a new window (from that terminal window) it automatically opens the new window as root (I didn't think this would cause issues, but it obviously did).

Code:

qxdisplay -o landscape -d ../../display/wayland-container-1

Initially I wondered whether it was working because I would run the above code, then select 'X session' in the GUI, and then run the below code in the attached terminal. I think it was the silly root thing.

Code:

 /mnt/guest/start_desktop.sh 0

Below are the resulting errors/info after running the scripts, if anything is useful to know.

Code:

[defaultuser@Xperia10 ~]$ /usr/bin/qxdisplay -o landscape --way
land-socket-name "../../display/wayland-container-0"
[D] unknown:0 - Using Wayland-EGL
[D] unknown:0 - Specified Desktop file does not exist "/usr/sha
re/applications/qxdisplay.desktop"
[W] unknown:0 - Theme dir "/usr/share/themes/jolla/meegotouch/z
1.5/" does not exist
[W] unknown:0 - Theme dir "/usr/share/themes/jolla/meegotouch/z
1.5/" does not exist
[W] unknown:65 - file:///usr/share/qxdisplay/qml/compositor/XWa
ylandContainer.qml:65: TypeError: Cannot read property 'surface
' of null

qxdisplay.desktop seemed to actually cause no issues, so apologies about that !!

Code:

root@Kali:/# /mnt/guest/start_desktop.sh 0
xauth:  file /home/user/.Xauthority does not exist

glamor: 'wl_drm' not supported
Missing Wayland requirements for glamor GBM backend
Failed to initialize glamor, falling back to sw
xinit: XFree86_VT property unexpectedly has 0 items instead of 1
The XKEYBOARD keymap compiler (xkbcomp) reports:
Warning:          Unsupported maximum keycode 774, clipping.
                  X11 cannot support keycodes above 255.
Internal error:   Could not resolve keysym Invalid
Internal error:   Could not resolve keysym Invalid
Internal error:   Could not resolve keysym Invalid
Internal error:   Could not resolve keysym Invalid
Internal error:   Could not resolve keysym Invalid
Internal error:   Could not resolve keysym Invalid
Internal error:   Could not resolve keysym Invalid

Errors from xkbcomp are not fatal to the X server

FYI, running this code gave the below error when starting the desktop:

Code:

qxdisplay -o landscape -d ../../display/wayland-container-1

Code:

root@Debian:/# /mnt/guest/start_desktop.sh 0

could not connect to wayland server
(EE)
Fatal server error:
(EE) Couldn't add screen
(EE)
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

Thank you again for your patience, and apologies for the ignorance !!

Last edited by spoofykid; 2021-05-29 at 10:37.

The Following 2 Users Say Thank You to spoofykid For This Useful Post:
juiceme, mosen

spoofykid | # 185 | 2021-05-29, 10:21 | Report

Just curious - I'm sure many have heard of the PinePhone - it has Mobian as a choice of operating system - can Mobian be installed as a container? Mobian operates well as a mobile desktop environment, and it would be great if it could be run within sailfish - Mobian is a bit easier to operate on a small screen compared to the normal desktop environment.

The Following 2 Users Say Thank You to spoofykid For This Useful Post:
juiceme, mosen

mosen | # 186 | 2021-05-29, 13:04 | Report

@spoofykid
when you have the x-wayland/qxdisplay window up.
Do you then attach to the container at all from another terminal as root and execute the start_desktop.sh within the container?

Code:

devel-su
lxc-attach -n <containername> /mnt/guest/start_desktop.sh 1

Sorry if i am captain obvious and you did all along. Just reading the backlog i found no mention.

Edit, yeah, you did. Sorry again.

Last edited by mosen; 2021-05-29 at 19:32.

The Following User Says Thank You to mosen For This Useful Post:
juiceme

spoofykid | # 187 | 2021-05-30, 02:44 | Report

@mosen

Yes, I did that multiple times. I think it was attempting to open x-wayland as root that failed for me. Though running /mnt/guest/start_desktop.sh 1 didn't work for me either - I have to run it with a '0' at the end instead of the '1' for the desktop to start.

Edit: I just realised what the 1 or 0 represent, and either work for me.

Last edited by spoofykid; 2021-06-02 at 20:14.

The Following 2 Users Say Thank You to spoofykid For This Useful Post:
juiceme, mosen

levone1 | # 188 | 2021-05-30, 03:30 | Report

Originally Posted by spoofykid View Post

@mosen

Yes, I did that multiple times. I think it was attempting to open x-wayland as root that failed for me. Though running /mnt/guest/start_desktop.sh 1 didn't work for me either - I have to run it with a '0' at the end instead of the '1' for the desktop to start.

Specifies in op to run command as nemo. That was likely your issue...

The Following 2 Users Say Thank You to levone1 For This Useful Post:
juiceme, mosen

Kabouik | # 189 | 2021-05-30, 12:51 | Report

Glad you got it working, you can have fun configuring your container now!

There's still something broken with the GUI for installing containers, setting up desktop and starting X, that we'll need to investigate, but there are multiple factors that may have confounding effects so that's not going to be trivial (OS version, device model, Sid is always changing…).

Last edited by Kabouik; 2021-05-31 at 11:25.

The Following 2 Users Say Thank You to Kabouik For This Useful Post:
juiceme, mosen

spoofykid | # 190 | 2021-06-02, 20:26 | Report

In case it's useful to anyone:

I install the desktop via the Containers GUI, run 'setup xsession' within the GUI, attach the container within the GUI, open a new terminal window, because it's root I run su defaultuser or if your user is nemo su nemo to get out of root, I run /usr/bin/qxdisplay --wayland-socket-name "../../display/wayland-container-0" from that window, minimise that and the "waiting for xwayland' windows, in the terminal window with the attached container run /mnt/guest/start_desktop.sh 0, and then finally minimise it and change to the "waiting for xwayland" window which should have the desktop running.

Obviously this has all been documented, but the big one for me was exiting root using su defaultuser before running the wayland code.

Last edited by spoofykid; 2021-06-07 at 18:33. Reason: Not sure why I put in nano instead of nemo

The Following 3 Users Say Thank You to spoofykid For This Useful Post:
juiceme, Kabouik, mosen