Skip to content
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

Open
ajanon opened this issue Dec 23, 2022 · 4 comments
Open

swhkd should grab all devices #191

ajanon opened this issue Dec 23, 2022 · 4 comments
Assignees

Comments

@ajanon
Copy link
Collaborator

ajanon commented Dec 23, 2022

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 to swhkd 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.

@ajanon
Copy link
Collaborator Author

ajanon commented Dec 23, 2022

This issue is for discussion and making sure we are not forgetting anything.

Notably, if we go forward with the --device argument deprecation, I am not sure how we should go about it. Is telling users in a changelog and printing some logs about this enough? Should we try to make it more visible to avoid having bug reports in the future?

@Shinyzenith
Copy link
Member

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.

@Shinyzenith
Copy link
Member

This issue is for discussion and making sure we are not forgetting anything.

Notably, if we go forward with the --device argument deprecation, I am not sure how we should go about it. Is telling users in a changelog and printing some logs about this enough? Should we try to make it more visible to avoid having bug reports in the future?

I think we can just exit on --debug and print that it's deprecated and that the flag itself will completely be removed at some version in the future.

@Shinyzenith Shinyzenith self-assigned this Dec 23, 2022
@Shinyzenith Shinyzenith pinned this issue Dec 24, 2022
@llitz
Copy link

llitz commented Jan 7, 2023

I came across swhkd and would like to offer other arguments to keep the --device. For example, I don't want anything grabbing all my devices because some devices should be sent to a different place (for example, a VM) or not used at all.

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.
evsieve creates a few devices (6 in total, 3 for host and 3 for guest). swhkd should only talk to one of the host devices.

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 --device option has already been coded, why not just leave it for those who need it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants