fix: avoid some wayland problems

[letsfindaway]

As distributions move from X11 to Wayland as default, more and more people are using OpenBoard on Wayland. However there are some known problems, e.g. the following:

• OpenBoard 1.7.0 on Wayland: Segmentation fault when clicking into the "List of screens used for Control, Display and Previous pages" entry field #843, Crashes using multi-displays - Flatpaks #1041
• [Bug] When RightLibPaletteBoardModeIsCollapsed=true the main Window stays invisible. #1164
• No screenshots and no screen mirroring in Desktop mode due to Wayland restrictions

The first two of these problems can be mitigated by using the xcb backend to force using xwayland. This PR sets the corresponding environment variable to enable the xcb` backend:

• use QT_QPA_PLATFORM=xcb when running on wayland
• avoids crash when using the screen configuration list
• avoids invisible window on Qt 6.8

Due to the severity of these problems I will include this PR in all by builds in the future and recommend to merge it as it has no impact for X11 sessions or for other operating systems.

[qqqqqqqqq9]

Hi,
with opensuse package (1.7.2) the Desktop mode is not working.
I only get a black screen.
When I build openboard myself, the desktop mode works.
When I start openboard with

QT_QPA_PLATFORM=xcb /usr/bin/openboard

I get a black background again.

[qqqqqqqqq9]

#847

[letsfindaway]

I cannot reproduced the black background on my side (Leap 15.6, but also on a tumbleweed distrobox). I only have a black screen on the mirroring monitor when activating screen mirroring, but yeah, a lot of wayland related issues remain.

BTW: Do you have multi-monitor mode enabled?

My observations:

• Without xcb, Desktop mode also shows the desktop for me, but the Desktop tools palette on the left side is hidden, as soon as I interact with an application. I have to reveal it by clicking on the OpenBoard taskbar icon - which is a Wayland icon. And then I can draw. But as soon as I use the pointer again to click through, the palette and the drawing vanishes. And when I try to configure my screen setup, OpenBoard crashes as soon as I click on the input field for the list of used screens.
• With xcb Desktop mode shows the desktop, but I cannot interact with it. I can draw something, but cannot click through to the applications.
• In both cases, screenshots and screen mirroring only get a black screen. Also podcast recording does not work for desktop mode.

My intention for using the xcb backend by default was the crash reported in #843. Let me phrase it this way:

We do not have a good solution for wayland. We can only try to make OpenBoard as usable as possible. And Desktop mode is broken with wayland anyway. So I have chosen what I think is more usable. And a only halfway working desktop mode was the lower price compared to a crash when configuring screens.

Anyway we recommend to use OpenBoard on an X11 session to use all features.

[letsfindaway]

Another note: I think that the Desktop mode as we have it in OpenBoard with X11 can never work on Wayland the same way.

OpenBoard places a transparent, invisible widget on top of the desktop. It can intercept events at will: Depending on the tool they are forwarded to the application below or used for drawing, while OpenBoard still stays in the foreground. This is something the security concept of wayland definitely wants to inhibit, as it would allow any kind of applications stealing user data.

You can already observe what Wayland does when you do not use xcb: When clicking on an application it brings this application to the foreground unconditionally. That's the reason why the OpenBoard tool palette and drawings disappear - they are now just behind the focus application. On X11, OpenBoard can still remain in the foreground in this situation.

If OpenBoard is in the foreground, as we have it with xcb, then it will not deliver any event to the applications behind. Therefore we cannot interact with them.

So that mixed mode we have on X11, where we can draw n the glass pane in front of the other applications while still delivering events through the "holes" outside of the drawings is not feasible with Wayland.

I started some work on using the Desktop Portal for screenshots and screen mirroring (https://github.com/letsfindaway/OpenBoard/tree/feat-wayland-screenshot) but stopped that again. First we would have to decide: What will be the future of Desktop mode on Wayland? Should we just accept that it will not work as before and completely remove it from OpenBoard? Do we have an idea for a desktop mode which can work with Wayland? I do not have an answer to those questions.

[qqqqqqqqq9]

BTW: Do you have multi-monitor mode enabled?
It's greyed out but looks pressed down.

My observations (without xcb)

I can

• open konsole (wayland-App)
• start geoenzo (Xwayland-App, via wine)
• use geoenzo normally (after disabling fullscreen)
• use OpenBoard to draw on the geoenzo-window
• use geoenzo agan.
  In my short test, it worked flawlessly.

Screenshot don't work with with openboard,
however I could use spectacle as a workaround.

We do not have a good solution for wayland. We can only try to
make OpenBoard as usable as possible. And Desktop mode is
broken with wayland anyway.

Is there a way to force OpenBoard to wayland-mode?
QT_QPA_PLATFORM=wayland /usr/bin/openboard didn't work.

You can already observe what Wayland does when you do not
use xcb: When clicking on an application it brings this
application to the foreground unconditionally.

That's not true. For me it works as intended.
Perhaps your focus-policy is interfering? I use kwin_wayland with Focus-follows-mouse and window-raising disabled.

First we would have to decide: What will be the future of Desktop
mode on Wayland? Should we just accept that it will not work as > before and completely remove it from OpenBoard?

IMO this is a No-brainer. Being able to draw on other apps so easily is a key feature of OpenBoard.

[letsfindaway]

Perhaps your focus-policy is interfering? I use kwin_wayland with Focus-follows-mouse and window-raising disabled.

Thanks for this hint. Yes, with your settings things look better. But how could we force users to use such a setting? What with other desktop environments, especially Gnome?

Still we have that crash. It now no longer appears directly when clicking on the input field, but when I click on one of the monitor indicators, which now however appear at the wrong location. I have that stack trace with the SEGFAULT:

[qqqqqqqqq9]

But how could we force users to use such a setting?

Here's what I would do:

1. create a wrapper-script which checks for QT_QPA_PLATFORM. If it's not set to wayland, it starts with QT_QPA_PLATFORM=xcb. That gives choice to users.
2. Explain the wayland/xcb-situation on openboard.ch. State that wayland works better with some setups and encourage to try it.
3. Open a discussion to collect setups which work with wayland and which do not.

You can't force people change their setup but you can give them choice. Also there might be setups in gnome which work well.
It's highly inconvenient to have a setup which doesn't work well, when you in front of 25 12-your-olds. This tends to motivate to change your settings.

As I understand, the crash can be easily avoided by not clicking into the mentioned field? I would add a "Not-TODO"-List.

I can write a draft for the section on openboard.ch.

[letsfindaway]

Thanks for all your comments, which gave me new insights into the problem field. I just converted this PR to Draft and am currently in favor not to merge it at all.

Here's what I would do:

1. create a wrapper-script which checks for QT_QPA_PLATFORM. If it's not set to wayland, it starts with QT_QPA_PLATFORM=xcb. That gives choice to users.

Together with your point 2., I would now even completely omit this and let it to the users and the explanation.

2. Explain the wayland/xcb-situation on openboard.ch. State that wayland works better with some setups and encourage to try it.
3. Open a discussion to collect setups which work with wayland and which do not.

I think Step 3 comes before step 2. So yes, feel free to open a discussion about his topic!

You can't force people change their setup but you can give them choice. Also there might be setups in gnome which work well. It's highly inconvenient to have a setup which doesn't work well, when you in front of 25 12-your-olds. This tends to motivate to change your settings.

As I understand, the crash can be easily avoided by not clicking into the mentioned field? I would add a "Not-TODO"-List.

I will investigate that further. If we don't find a solution, then I tend to disable the display of those screen indicators as workaround. They are even not correctly positioned on Wayland and therefore currently completely useless.

I can write a draft for the section on openboard.ch.

First start with the discussion here. I think the result may also go into a Wiki page here. But this is up to the maintainer.