-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
swhkd
should grab all devices
#191
Comments
This issue is for discussion and making sure we are not forgetting anything. Notably, if we go forward with the |
If this issue is implemented then do remember to add to README/FAQ that all device configurations should henceforth be made to the uinput device instead of the specific devices due to swhkd's grab. |
I think we can just exit on |
I came across swhkd and would like to offer other arguments to keep the To enable my VM separation and particular configuration, where only a portion of my keyboard is sent to the VM with media keys staying on the host, I use https://github.com/KarsMulder/evsieve. IMO, grabbing everything and forwarding all keys to a new device isn't a solution when other programs can also exclusively grab the devices. Since the |
This is a continuation of a discussion from #71.
First, a small summary of how device grabbing was implemented in
swhkd
as I understand it:To avoid grabbing all devices and swallowing their events (mouse cursor movements, for instance), a keyboard detection algorithm was first implemented in 8bbd34c. It checks if a given device is a keyboard by checking for the presence of the Enter key.
This was not completely correct, as some users still had their non-keyboard devices grabbed by
swhkd
(see #131) and this was causing other issues. For some others, some hardware keys were not recognized as keyboards (see #71).In answer to these issues, a
--device
argument was added toswhkd
in b53b8c. This allows users to explicitely tell what devices to use. With some configuration from users, this thus solves the issues.Ideally, users should not have to worry about what device
swhkd
should grab - it should do it correctly out of the box.In #163, we added support for re-emitting most device events from the grabbed device to the virtual uinput device of swhkd.
With this improvement, it should not be necessary anymore to avoid grabbing all devices, as
swhkd
can just re-emit events as needed. Additionally, the--device
argument is probably unnecessary and could be deprecated.The text was updated successfully, but these errors were encountered: