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