search

OpenBoard-org / OpenBoard

OpenBoard is a cross-platform interactive whiteboard application intended for use in a classroom setting.
https://openboard.ch/
GNU General Public License v3.0
2.41k stars 432 forks source link

fix: avoid some wayland problems #1165

Open letsfindaway opened 1 week ago

letsfindaway commented 1 week ago

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:

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:

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 commented 2 days ago

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 commented 2 days ago

https://github.com/OpenBoard-org/OpenBoard/issues/847

letsfindaway commented 1 day ago

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:

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 commented 1 day ago

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 commented 1 day ago

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

My observations (without xcb)

I can

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 commented 1 day ago

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: grafik

qqqqqqqqq9 commented 1 day ago

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 commented 1 day ago

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.

  1. Explain the wayland/xcb-situation on openboard.ch. State that wayland works better with some setups and encourage to try it.
  2. 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.