Only a single monitor out of three is locked when running in native wayland mode

[dvoloshyn]

Steps to reproduce the behavior:

1. Multi-monitor Gnome wayland session. Here is mine: MultiplMonitorsSetup.png
2. Start safeeyes in native wayland mode. To double check run xprop and try to click on safeeyes settings window. It should not be possible
3. Click 'Take a break now'
4. Only a single monitor is locked. In my case it's the top left one

Expected behavior
All of the monitors should be locked. When I run GDK_BACKEND=x11 safeeyes correctly locks all three monitors.

Desktop (please complete the following information):

• OS: 5.15.12-1-MANJARO SMP PREEMPT Wed Dec 29 18:08:07 UTC 2021 x86_64 GNU/Linux
• Desktop Env: Gnome 41.2 on Wayland
• Version: 2.1.3

Debug Log

• safeeyes --debug safeeyes.log
• GDK_BACKEND=x11 safeeyes --debug GDK_BACKED=x11-safeeyes.log

[Rosuavio]

I also have this issue on sway.

[vanarok]

I have the same problem. Laptop && Monitor. Sway. Solution: GDK_BACKEND=x11 and wayland - not work for me.

2022-10-28 12:22:17,505 [DEBUG]:[MainThread] Initialize the platform
2022-10-28 12:22:17,520 [INFO]:[MainThread] Starting Safe Eyes
Xlib.xauth: warning, no xauthority details available
2022-10-28 12:22:17,566 [INFO]:[MainThread] Initialize the break screen
2022-10-28 12:22:17,566 [INFO]:[MainThread] Load all the plugins
2022-10-28 12:22:17,566 [INFO]:[MainThread] Initialize the core
2022-10-28 12:22:17,567 [INFO]:[MainThread] Successfully loaded <module 'donotdisturb.plugin' from '/usr/lib/python3.10/site-packages/safeeyes/plugins/donotdisturb/plugin.py'>
2022-10-28 12:22:17,578 [INFO]:[MainThread] Successfully loaded <module 'notification.plugin' from '/usr/lib/python3.10/site-packages/safeeyes/plugins/notification/plugin.py'>
2022-10-28 12:22:17,579 [INFO]:[MainThread] Successfully loaded <module 'audiblealert.plugin' from '/usr/lib/python3.10/site-packages/safeeyes/plugins/audiblealert/plugin.py'>
2022-10-28 12:22:17,580 [INFO]:[MainThread] Successfully loaded <module 'screensaver.plugin' from '/usr/lib/python3.10/site-packages/safeeyes/plugins/screensaver/plugin.py'>
2022-10-28 12:22:17,581 [INFO]:[MainThread] Successfully loaded <module 'mediacontrol.plugin' from '/usr/lib/python3.10/site-packages/safeeyes/plugins/mediacontrol/plugin.py'>
2022-10-28 12:22:17,581 [DEBUG]:[MainThread] Initialize Skip Fullscreen plugin
2022-10-28 12:22:17,581 [DEBUG]:[MainThread] Initialize Notification plugin
2022-10-28 12:22:17,581 [DEBUG]:[MainThread] Initialize Audible Alert plugin
2022-10-28 12:22:17,581 [DEBUG]:[MainThread] Initialize Screensaver plugin
2022-10-28 12:22:17,581 [INFO]:[MainThread] Setting up an RPC server on port 7200
2022-10-28 12:22:17,582 [INFO]:[MainThread] Start the RPC server
2022-10-28 12:22:17,582 [INFO]:[MainThread] Start Safe Eyes core
2022-10-28 12:22:17,583 [INFO]:[WorkThread] Waiting for 52 minutes until next break
2022-10-28 12:22:22,214 [INFO]:[WorkThread] Take a break due to external request
2022-10-28 12:22:22,214 [INFO]:[WorkThread] Stop the scheduler
2022-10-28 12:22:22,214 [INFO]:[WorkThread] Pre-break waiting is over
2022-10-28 12:22:23,215 [INFO]:[MainThread] Close pre-break notification
2022-10-28 12:22:23,234 [INFO]:[WorkThread] Lock the keyboard
2022-10-28 12:22:23,236 [INFO]:[MainThread] Show break screens in 2 display(s)
2022-10-28 12:22:23,294 [INFO]:[MainThread] Moved break screen to Display[1680, 1570]
2022-10-28 12:22:23,297 [INFO]:[MainThread] Moved break screen to Display[1280, 0]

[vanarok]

I debugged the problem and found a workaround. In my case, two break screens do get created and for some reason they spawn in the same workspace. The workaround is to set the sway output for the break screen in the config. Break screen you may have a different number depending on which primary-display you have.
Ex, minimal solution:

for_window [title="SafeEyes-0"] move to output $output-secondary

[AkechiShiro]

This is still relevant on sway, I'm not sure if a fix would be easy to implement, maybe the workaround should be documented in the meantime

[mihalyr]

I just noticed something similar although on a single laptop display with multiple workspaces in Sway, only the current workspace is locked and I can switch to anywhere else, sometimes it locks right before I switch and I don't even notice the locked screen on the inactive workspace. This might be a different issue, though.

[shilkazx]

Same issue on Hyprland, Archlinux.

[nifadyev]

Could be related to #207

[deltragon]

This should be fixed by #561.

[mihalyr]

This should be fixed by #561.

I can confirm that the multi-monitor issue is fixed indeed, now it appears on both external monitor and laptop.

But the lock screen is only present on the current workspace, so switching to another, workspace there is no lock screen. Sometimes it happens that I am just about to switch when Safe Eyes kicks in and then the lock screen shows up only on the workspace I just left and not where I am currently. With the recent fix it at least shows up now on the second monitor to give me a hint. But it would be nice if the lock screen would apply to all workspaces, just like when I lock the session. Is this a different issue?

[deltragon]

@mihalyr Did you test with #561, or the latest version?
In theory, you shouldn't be able to switch workspaces at all, by inhibiting keyboard shortcuts...
(That is already the case on X11 with the latest version, and will be implemented for Wayland by #561.)
It is also possible, however, that Sway does not allow us inhibiting keyboard shortcuts. In that case, I don't think there's anything we can do, as I am not aware of an API to place windows on different workspaces.

[mihalyr]

Did you test with #561, or the latest version?

I tested with v2.2.2 the last released version.

In theory, you shouldn't be able to switch workspaces at all, by inhibiting keyboard shortcuts...

I can still use keyboard shortcuts on the lock screen.

I'm using Safe Eyes from Flatpak, btw. Let me know if you want me to test or debug something.

[deltragon]

@mihalyr That is a known issue then, as inhibiting keyboard shortcuts does not work on Wayland yet. (Needs #561 for that.)