Strange behavior with Librem5 VM


Because my soon-to-be-China-like country will probably soon impose using QRcode to go anywhere

I thought about doing a nice and practical QRcode reader for librem5

I downloaded the last qcow2 image of the librem5 and run it with qemu

I tried a webcam with mpv /dev/video0 : it successfuly get the video stream inside the L5 VM
Then I tried zbarcam to read QRcode : it works !

But then i found and installed the app qtqr , which didn’t start because I’m a dumbass who forgot to set DISPLAY=:0 when ssh-ing

After setting the DISPLAY variable, I found this very odd behavior :

If I execute qtqr from ssh it fails with the error :
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
I have same error/behavior with an other app

if I open the terminal inside the VM and execute qtqr : it fails with the same error
if I use the nice shortcut in the GUI application launcher : it fails to start, probably with the same error, but I can’t see it, I only see the desktop wallpaper
if I use zsh inside the current bash and execute qtqr : it fails with the same error

But then if I reboot with zsh as my default shell instead of bash, it works perfectly from ssh (but fails from terminal or GUI app launcher)
Anyone has a clue why ?

@amarok : did you tried qtqr (if not can you test it plz ? :pray: ) or any other QRcode reader ? (edit: hum, this request is kind of stupid, the cameras are not yet working…)

1 Like

Qt version in PureOS Amber (based on Debian Buster) is too old for sensible Wayland support (it doesn’t even support stable xdg-shell).

To run Qt applications, you have two options:

  1. Use Flatpak. Recent Qt versions should work just fine.
  2. Run Qt apps with QT_QPA_PLATFORM=xcb env var set to make them run via XWayland.

Once we switch to Byzantium (based on Debian Bullseye), Qt apps should work natively again as well.

The image I actually use is :

lsb_release -a
Release:        10.0
Codename:       byzantium
uname -a
Linux pureos 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 GNU/Linux

I think I downloaded the Build #6355 (11 janv. 2021 19:32:31)

I tried to launch qtqr with QT_QPA_PLATFORM=xcb (when default is bash) : it works !

it doesn’t explain the working behavior with zsh, but is enough of a solution/explanation for me ! thx :wink:

On byzantium, it should start to work after sudo apt install qtwayland5.

It works from zsh probably because it ignores /etc/profile.d, which includes QT_QPA_PLATFORM=wayland on our images.

Okay, everything is clear now, thx for the precision !

Will qtwayland5 be installed by default ?

I installed qtwayland5 and tried it again : it works but differently from when I use zsh

When I use zsh by default, the window is autosizing to the current resolution, which makes it ugly, but usable :

When I use bash by default, windows does not autosize anymore, which makes it nicer but unusable :

Is there somewhere a parameter to configure this autosize by default ?

The first screenshot has it running via XWayland. The second one shows it running on Wayland natively. You can use the previously mentioned

AFAIK qtwayland5 is in Qt’s recommended packages, and currently we don’t install recommended dependencies. This is supposed to change before Byzantium becomes the default (right now it’s still Amber).

okay that’s so great !

I tested changing QT_QPA_PLATFORM=wayland to QT_QPA_PLATFORM=xcb in /etc/profile.d/
now I have the same behavior in all cases because it uses XWayland all the time

I understand the change I made is not a good long term tweak
The QT_QPA_PLATFORM=xcb should be set case by case in the launcher or alias of the app you want working with XWayland

For those who could be interested, here an exemple for qtqr :
You need to edit the file /usr/share/applications/qtqr.desktop and modify the line
Exec=qtqr %F
Exec=env QT_QPA_PLATFORM=xcb qtqr %F

1 Like

I wonder if qtqr would work much better on small screens when by dividing the window horizontaly instead of vertically so that the text input field is abhove the area which displays the qrcode, or vice versa. Would it be worth to talk with qtqr developers about that?