Thanks, Trevor. I think your conjecture is correct. I'm fine with it being implemented within the compositor itself, as long as they provide some sort of configurable option (or options). Ideally, it would be nice to have functionality equivalent to "unclutter", where you can set a delay for blanking/hiding the cursor, and have it monitor activity to unblank/unhide as needed. (That would be nicer, since it would allow for easier testing and debugging of problems.) But, at this point I'd even settle for a global setting to just eliminate the cursor entirely, since it will not be needed for either of the 2 kiosk-mode applications I'm thinking of. (One is display-only, with no user interaction, and the other would be using a touch screen, with no keyboard or other pointing device.) I'm holding off on moving away from Xorg (with chromium as the client app in one case, and a custom Python app in the other, neither of which I'd want to modify myself) until this is resolved. I'm not in a big hurry, but I am realizing that Xorg's days of being supported in most distros are coming to an end. Also, I've noticed a huge performance benefit to running chromium on Wayland instead of Xorg - about half the CPU usage and load average on a Pi 4! So, I'd migrate to Wayland sooner, if I could just get rid of the stupid cursor. RANT: If Wayland is supposed to be the "one true way forward", you'd think they'd consider use cases beyond the standard interactive desktop! Kiosk-mode applications are not that rare that this would be a weird corner case unworthy of developer attention! Why are developers today so insistent on change yet so myopic about real-world use cases?! Gilbert On 2025-04-04 5:23 a.m., Trevor Cordes wrote:

On 2025-04-03 Gilbert Detillieux wrote:

...

Hi folks.

I'm trying to find something equivalent to "unclutter" or "xbanish" that will allow me to hide the mouse cursor when I'm running Wayland's labwc compositor. This is for a kiosk-mode application, using a Raspberry Pi and Debian 12 (Bookworm).

I would think that this would be a feature that would have to be provided by the compositor. One of the main ideas behind Wayland is to "protect" the desktop against programs doing anything beyond their own limited control space (i.e. a window). So using a 3rd program to cause changes in the 1st program, or Wayland itself, is probably impossible.

Doing global stuff to mouse cursors would seem to fit the bill of prohibited actions.

I could be wrong, this is just going by my years of research into getting the functionality I get with sawfish WM out of Wayland, should TPTB at RH/Fedora decide to ditch Xorg completely. And the main thing I've learned is everything "global" in nature, or "outside the window" (even frame decoration behavior!), must be done in the compositor.

There is another avenue of attack, though. The program should have control of the cursor within its own window. So if you had, say, a full-screened kiosk GUI app running, presumably that app could hide the cursor (like terminals do when typing). So perhaps you can look to using a program that can be set to hide the cursor, or modify an open source program to add that feature.

(Disclaimer: all of the above is mere conjecture! I don't use awful, dumb, useless, regressive, forced-change, adds-nothing-I-care-about, should-be-killed Wayland; and long may I postpone that day!)

-- Gilbert Detillieux E-mail: Gilbert.Detillieux@umanitoba.ca Computer Science Web: http://cs.umanitoba.ca/~gedetil/ University of Manitoba Winnipeg MB CANADA R3T 2N2 For best CS dept. service, contact <cs-support@lists.umanitoba.ca>. _______________________________________________ Roundtable mailing list -- roundtable@muug.ca To unsubscribe send an email to roundtable-leave@muug.ca

On 2025-04-04 Gilbert Detillieux wrote:

RANT: If Wayland is supposed to be the "one true way forward", you'd think they'd consider use cases beyond the standard interactive desktop! Kiosk-mode applications are not that rare that this would be a weird corner case unworthy of developer attention! Why are developers today so insistent on change yet so myopic about real-world use cases?!

You predicted exactly what I was going to say when reading your reply: Wayland, like most modern "redos", is generally pretty good at its common use case. What no one seems to consider anymore is the zillions of alternative use cases or unique needs of picky users. Things that evolved over 40 years of use and mods to X. Everything Lennart & co & Wayland did was good for a laptop user with common use cases. But so much of it makes no sense on a server or even a power-user workstation. Lennart's idea that home dirs should be encrypted and so sshd can't access user keys is the prime case in point. So that's why your Chromium is faster on Wayland, because it was designed to basically do just that (and some "security" stuff) and not much else (well, I guess 3D effects wooooo). But if you want unclutter or sawfish-programmable behaviors or remote clients, you're SOL. (Wayland is faster for Chromium because it removes the entire layer that allows for "remoteness"; it's not faster because it's written better, it's faster by design with specific, known, limitations and "downgrades".) Don't be so sure X will completely go away, though. All the BSDs use it and can never use Wayland because it's tied to all the Lennart-"kit"-isms and systemd. Therefore there will always be a Devuan-style rebel distro. The only question will be how painful a transition to that type of distro will be. Or we need the wizards who made all of the uber-programmable sawfish et al to team up and make a compositor (which they say they can't/won't). Or maybe KDE, who did, will be the savior. But they seem to have switched from "infinitely configurable" to "dumb it down" as a mantra. Like we need another GNOME... I also worry about the phone-ization aspect of Wayland. It was those phone OSes that invented (for Linux) the idea of GUI protection inter-app because they knew they were going to open the stores to zillions of unverified(able) apps. The open-source / rpm economy of (official) distro packages exists at a higher trust level in comparison. Maybe they are setting us up for tightly controlled, *forced* "app stores" on the linux desktop too. Can't have people with too much computational freedom (see also: Secure Boot)!