[feat] --add-device --ignore-device

[Shinyzenith]

Mutate keyboard list at runtime.

The current --device argument should change to --add-device to append to the list and --ignore-device for the vice versa

[seocamo]

+1, so people with logitech mice can ignore the mouse as they also got a keyboard device as extra keys and so swhkd stop the mouse working, the device is not great as i use a laptop and i got more then 1 keyboard, so ignore would be so much better :D

[Shinyzenith]

We now reemit mouse events just in case that it gets grabbed. Essentially this means mouse keybinds should work now too? I haven't tested it yet but adding the functionality will be trivial.

Would you mind testing master branch?

[seocamo]

i cloned the main branch(as there is no master branch), and i build it and it work just fine with the mouse, nice work.

but sometimes when logout and then back in to sway,(i think maybe i was in i3 each time) the system lock up, i can't go to a tty, the monitor did not upload the time, never try that before, the only way was the power button.

i try this 6 times today, i can't get any info from -d as i can do this without relogin sway. i have added killall swhks && killall swhkd to my startup script, maybe this fix it as it has been a hours since last time it lockup.

i try to see if i can some how get some info for next time it lockup, ex. swhkd -d > log.txt i will post it here if i get any.

Edit: it don't lockup as much as i was thinking as i get dunst notications while it lockup so it is keyboard and mouse that is lock.

plus it lockup again with a run script like this, and i don't get any output in the log file when it happen. #!/usr/bin/env bash killall swhks killall swhkd swhks & pkexec swhkd -c ~/.config/sway/swhkdrc

[Shinyzenith]

Hm @ajanon can you reproduce this by any chance? I'm aware of some session issues but haven't had them myself.

[ajanon]

I did encounter this issue with swhkd.

@seocamo Your system is not completely locked up as you expected, but as swhkd grabs all devices exclusively there is basically no simple way to recover. If it happens again, there is a workaround:

• Ensure your system is set up to listen to Magic SysRq keys (you may need to reboot first if you change sysctl files):
  • https://wiki.archlinux.org/title/keyboard_shortcuts#Kernel_(SysRq)
  • https://en.wikipedia.org/wiki/Magic_SysRq_key
• When your system locks up, use the Unraw Magic SysRq key (Alt+SysRq+R)
• You should now be able to switch to another tty (Ctrl+Alt+F{1, 2, 3, 4, 5, 6})
• In the tty, login and kill the swhkd process (sudo pkill swhkd should work, if not, force-kill with sudo pkill -9 swhkd)

This is not ideal, but this should avoid rebooting forcefully.

I am not sure why this happens as of today. I have some suspicion that udev support might solve this issue. If you can, could you please try to build swhkd from the udev_sync_busy branch? (https://github.com/waycrate/swhkd/tree/udev_sync_busy) Please note that this build will use a lot of your CPU time (if you have a multicore system, I expect it will use one core entirely), so please run it only for testing.

[seocamo]

sorry it has been so long, busy on work, i try to find some time soon to test.

edit: don't look like i get any time anytime soon.