hide cursor about cage HOT 15 OPEN

From what I understand, they should already be supported, but only if you're using hardware cursors (although I've never figured out how to fix the warn: wayland.c:1512: no server-side cursors available, falling back to client-side cursors message, and WLR_NO_HARDWARE_CURSORS=0 doesn't change this)

from cage.

Though to answer your question, run sudo libinput list-devices to check for pointer devices, which would be indicated by the Capabilities: pointer line.

from cage.

Current logic is quite "simple". If any input device has pointer capability, show the cursor. If not, do not show any cursor. This is how I understand it.
Tranparent cursor or removing images loaded by Xcursor should do the trick for your case.

from cage.

I have a (admittedly janky) solution to hiding the cursor, which is just removing or hiding /usr/share/icons/*/cursors from cage (e.g. Set InaccesiblePaths=/usr/share/icons/ in the systemd service that executes cage).

Outside of that hack, or this patch, I don't believe cage provides a way to disable the cursor; trying some of the WLR_* env vars from this cursor-related patch didn't seem to work.

from cage.

Thanks for the tip! I also noticed setting the XCURSOR_THEME seemed to have no effect as well. I wanted to set it to this theme here: https://github.com/johnodon/Transparent_Cursor_Theme

I ultimately ended up replacing all the themes with the above mentioned to get it to work, but I like the inaccessible path approach better frankly. I'll try that and see if it takes effect.

from cage.

InaccesiblePaths=/usr/share/icons/ didn't work for me :( let me know if you get that working properly and maybe send over an example.

from cage.

Hmm, you're right. Ironically, I was assuming a cursor package I installed was what allowed me to see a cursor in cage, so you discovering that has made my life a little simple (thanks for that!), but yeah, I'll need to do some investigating into how I managed to break cursors in the first place.

EDIT: Okay, so cage uses client-side cursors, which usually means that the XCURSOR_* env vars aren't respected in most Wayland clients. But also, the reason my cursor wasn't showing at some point in the past was because I was using a different renderer for cage (a non-pixman renderer), which is what broke them originally

from cage.

If I remember correctly, if no pointer input is available no cursor should be displayed by Cage. Could you check the inputs seen by the compositor?

from cage.

How would I check the inputs? Sorry for the ignorance, don’t really know what I am doing as it relates to the compositor :(

Based on my ignorant reading of the relevant PR my understanding was that if a touch device is found it hides the cursor. Subtly different from no pointer devices found (which should be my case). But even if a pointer device is present I prefer to make it disappear after a certain inactivity timeout. When I was messing with sway it had setting of this nature (which incidentally didn’t work when set in the config file but did work if I sent a swaymsg).

Regarding the cursor env vars, those variables are actually explicitly called out in the docs as supported so we probably want to update the docs if indeed they are ignored.

from cage.

Maybe this is why it still shows up for me even if I don't have a keyboard/mouse plugged in?

libinput list-devices
Device:           vc4-hdmi
Kernel:           /dev/input/event0
Group:            1
Seat:             seat0, default
Capabilities:     keyboard pointer 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   *button
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   flat *adaptive custom
Rotation:         n/a

Seems odd an hdmi device is a keyboard and a pointer but I suppose it's something to do with cec?

from cage.

This pointer device should be exactly why a cursor is displayed: here in the code. HDMI-CEC seems to be a good explanation.
Maybe you can disable it at udev / libinput layer as there is no option (yet?) to disable cursor in Cage.

from cage.

Thanks for looking that up! I think the transparent cursor is the better option in my case as someone may have a mouse plugged in etc. That should work perfectly well until a proper inactivity or similar solution is available.

I think the current logic (as I understand it) is sound:

• if any touch devices present hide the cursor
• If 0 pointer devices present hide the cursor

additionally the 3rd bit would be:

• if pointer is visible (no touch devices present) then hide after x period of inactivity.

As an interim solution, maybe it would be possible currently to default the position to the upper left corner or something instead of sitting dead center of the content area. Would at least make it a little less noticeable.

from cage.

Yeah, would be good to understand why the env vars don't seem to be working. For example setting the cursor path to /dev/null would be cleaner than replacing all cursors...or even setting the theme properly would be great as well. Perhaps I have something messed up on my end preventing those from working as desired?

from cage.

Here are two possible solutions with udev:

• To ignore an input device: https://wayland.freedesktop.org/libinput/doc/latest/ignoring-devices.html#ignoring-devices
• To only enable the keyboard capability on a specific device (and disable all other capabilities including pointer): https://wayland.freedesktop.org/libinput/doc/latest/device-configuration-via-udev.html#udev-device-type

from cage.

Cage handles the cursor differently than Weston. When I start the same electron application with cage as compositor, there is a cursor in the center of the screen (although only a touch screen is connected, no mouse). When I start the application with weston as compositor, the cursor is NOT displayed. So it would be nice if cage could use the same logic for displaying the cursor as weston does.

from cage.