Description of problem: If xscreensaver is installed (e.g. when another DE such as xfce is installed on the host), it will lock the screen in Wayland/Xwayland as well when GNOME on Wayland is selected. Unfortunately, there is no way to unlock xscreensaver if started in Wayland as the focus remains in the Wayland windows underneath, only solution is to ssh to the host if possible and kill xscreensaver to recover the Wayland session. Version-Release number of selected component (if applicable): xscreensaver-base-5.32-9.fc22.x86_64 How reproducible: Always Steps to Reproduce: 1. Select "GNOME on Wayland" session in gdm 2. Start an X11 based app 3. Wait for xscreensaver to kick-in and lock the screen or, if you are in a hurry 1. Select "GNOME on Wayland" session in gdm 2. Open gnome-terminal 3. Run "DISPLAY=:1 xscreensaver-command --lock" Actual results: xscreensaver start and lock te screen after some time and there is no way to unlock. All characters typed are sent to the last focused Wayland window Expected results: xscreensaver is not started Additional info: None
I suspect xscreensaver gets started with: /etc/xdg/autostart/xscreensaver-autostart.desktop Ideally this should not be started on "GNOME on Wayland"
Actually this autostart file should be dropped from the package xscreensaver-base, it's of no use since GNOME has its own screensaver.
So does this mean that XGrabKeyboard() or XGrabPointer() are "broken" with XWayland?
Or, in other words, are there any alternatives on XWayland what XGrabPointer(..., ButtonPressMask | Button1MotionMask |.... ) did with X?
I don't quite think the problem is how Xscreensaver grabs the keyboard/mouse. The problem is simply that Xscreensaver is started in Wayland, while it should not. And it does so because the package includes an autostart desktop file that tells the session manager to run it in GNOME, which is now irrelevant, even in X11, because GNOME has its own screen lock mechanism and don't need Xscreensaver.
This is still an issue. Just install GNOME and xfce (which will pull xcreensaver) on F22 and log in GNOME on Wayland to get stuck because of screensaver once it's taken over the display. The simple solution is to drop /etc/xdg/autostart/xscreensaver-autostart.desktop from the package. This file is of no use because GNOME has its own screensaver and xfce has its own xsccreensaver autostart desktop file.
So again what I see it problematic is that your comment seems to be saying that if you - explicitly disable GNOME screensaver - launch xscreensaver on GNOME on Wayland still xscreensaver cannot unlock the window and in that case I think Wayland is broken.
And on X11 even if xscreensaver is running, if xscreensaver fails to grab keyboard or so xscreensaver won't try to lock screen, so it should be safe even if xscreensaver is running. So if this mechanism does not work on GNOME on Wayland, _this_ should be fixed.
(In reply to Mamoru TASAKA from comment #8) > So if this mechanism does not work on GNOME on Wayland, _this_ should be > fixed. Unlike X11, Wayland has no grab mechanism. see [1]: "The compositor maintains an implicit grab when a button is pressed, to ensure that the corresponding button release event gets delivered to the same surface. But there is no way for clients to take an explicit grab. Instead, surfaces can be mapped as 'popup', which combines transient window semantics with a pointer grab." But xcreensaver is an X11 application (not ported to Wayland) so it's running on Xwayland and obviously no other X client (running on Xwayland) have an active grab at that time. TBH, relying on an tentative explicit grab to fail to determine if Xscreensaver should take over the screen lock doesn't seem like a reliable design anyway. But anyway, I'm not sure what you want to fix there, Xscreensaver would need to be included in the Wayland compositor for this to have a chance to work [2] and that'd be pretty useless anyway in the case of GNOME because GNOME has its own locking mechanism. [1] http://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Input [2] http://ppaalanen.blogspot.fr/2011/11/screen-locking-in-wayland.html
I do agree there is a focus issue with mutter though, because the xscreensaver unlock dialog should receive keyboard events after the GNOME screensaver gets unlocked - But that's another issue, xscreensaver should not be started in the first place IMHO.
I tried modifying xscreensaver lock dialog code to set focus explicitly on map, but it causes a race condition with mutter so it's still fairly unreliable. So I've opened upstream bug b.g.o 752956 for the focus issue.
In what use case would the current /etc/xdg/autostart/xscreensaver-autostart.desktop be useful? If I understand it right, it only attempts to run xscreensaver when used inside a Gnome session, and Gnome always has its own screen locking mechanism available.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.