Open ajanon opened 1 year ago
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?
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.
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.
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?
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.