Grab error when using keyd

[pallaswept]

I was just doing some testing on a build that I have had working in the past, but every time I clicked the gesture button I'd get the following error:

[2023-08-03T15:26:23Z ERROR mouse_actions::process_args] Grab Error: IoError(
        Os {
            code: 16,
            kind: ResourceBusy,
            message: "Device or resource busy",
        },
    )

I was briefly baffled as to why this known-good copy of mouse-actions was suddenly failing, and after some testing realised that the problem was that I had recently enabled keyd. When I stopped the keyd service, mouse-actions instantly worked as per normal.

I'm honestly unsure if this is a keyd bug or a mouse-actions bug, or both, but I do know they are both indispensable tools for accessibility for disabled users, and we very much need them to coexist, so I'm filing issues in both places. Here is a link to the keyd issue: https://github.com/rvaiya/keyd/issues/548

[rvaiya]

In general, keyd is incompatible with other programs which use evdev to grab input devices. In this case, it seems the problem is that the program is generating a bunch of uinput devices (you can verify this by looking at the evtest output), which causes keyd to crash and should probably be considered pathological behaviour.

[pallaswept]

it seems the problem is that the program is generating a bunch of uinput devices

I can see from a quick glance at this that rdev (the crate this application uses to grab evdev) generates a uinput virtual 'clone' of every 'real' device it sees in /dev/input, which at least in my case, when I double the number of real input devices, will take me well over the 64 device limit coded into keyd. So, that explains the Assertion 'n < MAX_DEVICES' failed. error that I've seen.

In general, keyd is incompatible with other programs which use evdev to grab input devices

That's a real shame, it seems very powerful but there are many other needs to grab input devices (this mouse gesture app for example) so I might have to find an alternative but it doesn't seem like any exist. The only other suggestion I've found is swhkd and it doesn't grab the input so while it runs the command as instructed, it also passes the original keypress on to the WM which makes it useless for me :(

Thanks for taking the time to explain it to me :) I guess this is another "Wayland isn't ready yet" kind of situation :( But I can't use X11 or Windows either.... I'm screwed.

[pallaswept]

For what it's worth, I've tried a few other similar tools, a good example is https://github.com/sezanzeb/input-remapper/ and the result is identical. Only one application seems to be able to grab evdev devices at any given time. That's a real problem, but I think it's probably one that exists in the kernel's input system, and not in this or any other app.

What is the best course of action here? I think it seems like "give up", which kinda sucks :(

[4680864]

I use two keyboard layouts. When I run mouse-actions, the setxkbmap -option grp_led:scroll setting stops working, and the scroll-lock led stops turning on/off when I switch layouts. I think this is the same problem that pallaswept has.

This is critical for me. I had to go back to easystroke.. although I liked mouse-actions very much, and I will wait for the fix.

[pallaswept]

I think this is the same problem that pallaswept has.

I don't see any relationship between these issues. Yours is entirely X11-specific, and this is evdev- and Wayland-specific. X11 apps have no need for the exclusive access to the evdev input devices that wayland does. You might want to look into it some more....

[mingti]

Hi guys, I think I solved this problem by using setkeycodes to map the keyboard so I don't have to use evdev. https://wiki.archlinux.org/title/Map_scancodes_to_keycodes

[pallaswept]

Thanks for sharing that workaround. Unfortunately scancode remapping won't quite solve this. Happy New Year :)