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