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
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=
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.
Fedora 34 seems to be available for Raspberry Pi, you could install it on a spare SD card for reproducing.
Or... hear me out... someone who's already running it could answer my questions.
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!
Mars is the only planet in the universe that has a Linux system with working power management and sound.
I can report that on a Debian testing system under Wayland, I get similar behaviour.
driver/test-xinputgives 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,xlogofor instance,driver/test-xinputproduces 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
-graboption todriver/test-xinputcauses a pointer grab, your conjecture at the end seems to be appropriate. Whendriver/test-xinput's grab is active,xevstops seeing my pointer events, but I can still select text in GNOME Terminal.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".
C.
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 :-()
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...
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...
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.
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?
That will change if GDM uses wayland, which it has since F23.
If a user wants to not run wayland with their DE they can click on their login name in gdm, then the little cog at the bottom right and use the "Gnome on Xorg" option to run Gnome on X11.
As noted in the docs: https://docs.fedoraproject.org/en-US/quick-docs/configuring-xorg-as-default-gnome-session/
Xscreensaver works as expected with that for me. Or maybe they can use Enlightenment. That doesn't use wayland on Fedora by default yet.
Derp. you're right about /etc/gdm/custom.conf too.
That link says "Wayland has been the default since Fedora 25", but the reports I'm hearing are "XScreenSaver 6.00 was working on Fedora 33 but not on Fedora 34". So what changed in 34?
Well, Gnome 40 is new in F34 so probably lots of changes in XWayland like https://www.phoronix.com/scan.php?page=news_item&px=GNOME-40-XWayland-On-Demand. Also Pipewire, which manages audio and video streams and how they connect between apps.
You'd have to ask "Researchanddetailsweb" really.
Also this https://www.phoronix.com/scan.php?page=news_item&px=XWayland-21.1-Released
When I said "what changed" I wasn't really asking, "I wonder if Fedora 34 has made any changes at all since Fedora 33." I think we can assume that it did. And that audio has nothing to do with keypresses.
The salient question is, if Xorg was in fact being run under Wayland in Fedora 33, then why was my X11 app able to receive events properly then, but is not in 34? Followup question, how do users get the old behavior back?
I can't answer the salient question. The Follow up is easy though, use Gnome on Xorg.
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.
https://github.com/swaywm/swaylock
C.
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.
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.
C.
Also, I'm more than a little disappointed that isthistheyearofthelinuxdesktop.org does not exist.
C.
Can anyone tell me how to make the KDE login session use plain old Xorg instead of Wayland/XWayland?
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.
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.
"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/.
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.