XScreenSaver Wayland shenanigans

Dear Lazyweb,

I've had a couple of people report that after upgrading to Fedora 34, XScreenSaver 6.00 has stopped being able to detect user activity and activates prematurely. From the logs they sent, it looks like the XInput2 extension still exists but has stopped working entirely. No events are printed by driver/test-xinput (with no args, or with -grab -kbd-async -mouse-async). Can anyone confirm or deny this?

Actual photos of X11 / Wayland integration.

The server is still X.Org 12101001, however it was launched by sddm / startplasma / Xwayland and the environment contains XDG_SESSION_TYPE=wayland and WAYLAND_DISPLAY=wayland-0. So maybe it's Wayland that is screwing everything up? One user was using Gnome and one was using KDE.

Maybe there's a way to configure the system to go back to running "real" X11 instead of whatever fresh hell of X11 / Wayland hybridization this is?

Or is there some way for me to infect Raspbian 10.9 with this hybridization so that I can reproduce it myself?

Related question:

At some point in the distant past, I convinced myself that Wayland was incompatible with XScreenSaver locking, and therefore XScreenSaver refuses to lock when $WAYLAND_DISPLAY is set. I commented this change with "X11 grabs don't work under Wayland's embedded X11 server. The Wayland window manager lives at a higher level than the X11 emulation layer."

However, now I can't find any record of what the actual problem was. Do you know?

My guess is that it's something like running X11 under macOS: the grabs stay inside the X11 app, but you can still use Cmd-Tab to switch away to non-X11 apps even if X11 thinks things are "locked" inside its little sandbox. But I don't remember.


Tags: , , , , ,

27 Responses:

  1. GDR! says:

    Fedora 34 seems to be available for Raspberry Pi, you could install it on a spare SD card for reproducing.

    • jwz says:

      Or... hear me out... someone who's already running it could answer my questions.

    • erichbf says:

      So I will take a look on my Fedora laptop, but I wanted to mention I had an issue with openSuSE, though issue was that upon waking up, I have login to a console and restart my xsession.

      Crime in my neighborhood is increasing without the cow trampoline team, so whatever is happening, this is a critical bug. Please help!

      • jwz says:

        Mars is the only planet in the universe that has a Linux system with working power management and sound.

  2. Ben Harris says:

    I can report that on a Debian testing system under Wayland, I get similar behaviour. driver/test-xinput gives no output both when run with no arguments and when run with -grab -kbd-async -mouse-async. There is an exception, though. If I run an X application, xlogo for instance, driver/test-xinput produces output when the mouse pointer moves within the X application's window, or when I type with the input focus on the X application. This suggests that it only sees input that passes through Xwayland.

    Assuming that the -grab option to driver/test-xinput causes a pointer grab, your conjecture at the end seems to be appropriate. When driver/test-xinput's grab is active, xev stops seeing my pointer events, but I can still select text in GNOME Terminal.

  3. Carlos says:

    Not an expert by any means - but it was my understanding that it's a deliberate design choice - Wayland clients cannot see input events or output from other Wayland clients, as a privacy/security thing.

    So I think you might be seeing Wayland just providing fake APIs - "sure, I'll let you grab the input, but you'll just never see anything coming in".


  4. John Morton says:

    Past you was on the right track. The Wayland protocol developers consider having a client program implement screen locking is silly and instead regard that as a job for the Wayland compositor. Which is fair enough, really.

    Which means running xscreensaver under Xwayland will never work, and writing "wscreensaver" probably doesn't make much sense either, even for the compositors with broad plugin architectures. However, figuring out ways to integrate the xscreensaver screen hacks collection with existing compositors might be asking the right question.

    (The answer might be "a shitshow" of course; I'm yet to upgrade to a version of KDE under X.org that doesn't require patching to allow me to run xscreensaver, so I haven't got that far :-()

  5. Erin Shepherd says:

    My guess is that it's something like running X11 under macOS: the grabs stay inside the X11 app, but you can still use Cmd-Tab to switch away to non-X11 apps even if X11 thinks things are "locked" inside its little sandbox. But I don't remember.

    Your guess is pretty much entirely correct (in fact I think Xwayland and Xquartz share a lot of the code that makes rootless X servers work)

    X11 apps under Xwayland only see input events while the mouse is over an X11 window (in fact I've taken to using Xeyes as a "Wayland or X11?" debugger)

    I don't think there's a standard interface for screen lockers under Wayland, so someone would probably need to bridge Xscreensaver to the handful of different ones that exist...

    • jwz says:

      Oh god, there are like a dozen "Wayland screen lockers" on GitHub that all look to be 30% finished, "my first Wayland program" attempts, and yet, already 20,000 lines long.

      It's like watching a baby totter toward a porcupine...

      • Nibby says:

        Why did I ever think it would be hard to hate a window sysmtem more than X11? But ‘porcupine’ is a good name for one.

  6. jwz says:

    Perhaps the solution for Fedora 34 is to set WaylandEnable=false in /etc/gdm/custom.conf and reboot. Can someone running Fedora 34 let me know if that solves the XScreenSaver problem, and whether it causes other obvious problems?

    Is there also some GUI configuration tool to change this setting?

  7. Carlos says:

    Did you find Swaylock in your travels? It claims to be a complete screen locker implementation, compatible with a variety of compositors, and is about 3k lines of C.

    I'm not using Wayland myself - Cinnamon desktop doesn't support it yet, and may never do so - so I'm afraid I can't offer any real experience with it.



    • jwz says:

      I stopped reading when I got to: the way you run make is not by typing "make".

      In case anyone is under any misconceptions here, XScreenSaver will never be rewritten as a Wayland program, so that's not what I'm asking. The day that Linux systems foot-gun themselves to the extent that they stop supporting screen-saving using the X11 protocol is the day that XScreenSaver stops supporting Linux. It will then run "only" on macOS, iOS and Android.

      "Truly this is the year of the Linux desktop."

      So good luck with that.

      • Carlos says:

        Absolutely fair - and I wasn't expecting you to rewrite XScreenSaver for Wayland. I wasn't sure if this gave enough of a clue to build a Wayland shim that talked to a mostly-unchanged XScreenSaver. I've never programmed X, so I don't even know if that makes sense with Wayland's render-in-the-client design.

        I also have open-source projects that are likely to never receive major updates because of huge breaking changes in the underlying layers, so I feel your pain there.

        FWIW, thanks for all your work on XScreenSaver lo these many years.


      • Carlos says:

        Also, I'm more than a little disappointed that isthistheyearofthelinuxdesktop.org does not exist.


  8. jwz says:

    Can anyone tell me how to make the KDE login session use plain old Xorg instead of Wayland/XWayland?

    • cleanslate says:

      Rename /usr/share/wayland-sessions to /usr/share/wayland-sessions-disabled (or change the SessionDir line for [Wayland] in /etc/sddm.conf), then make sure /etc/sddm.conf contains an [X11] section with the line SessionDir=/usr/share/xsessions. That directory must then contain a .desktop file (probably plasmax11.desktop) whose [Desktop Entry] section must have a line Type=XSession. To make autologin work put an [Autologin] section with lines Session=plasmax11.desktop and User=jwz in /etc/sddm.conf. F34 ships sddm 0.19.0 which made Wayland the default and thus broke everything relying on X11 being the default.

      • jwz says:

        Wow, that is... a lot. Can those instructions be pared down to "add these exact lines to these files" and have less "if" and "make sure" in them? The other installation instructions in the manual are already pretty complicated, but this sounds even worse.

        • cleanslate says:

          "In /etc/sddm.conf under [Wayland] change the SessionDir line to SessionDir=/nowhere and if /usr/share/xsessions/ is empty install a window manager that places a .desktop file there."

          After that sddm should no longer offer the sessions from /usr/share/wayland-sessions/.

          • jwz says:

            Better, but if someone said to me "if /usr/share/xsessions/ is empty install a window manager that places a .desktop file there" I would just stare at them in blank incomprehension.

  • Previously