keyboard rates on X11 are changed

[loiccoyle]

Version Information:

• uname -a :
  Linux FrameWork 5.16.12-arch1-1 #1 SMP PREEMPT Wed, 02 Mar 2022 12:22:51 +0000 x86_64 GNU/Linux
• swhkd -V :
  swhkd 1.1.2

Describe the bug:
When on X11, the keyboard's delay and repeat rates are not respected. They get set to delay: 660 and repeat: 25.

Expected behavior:
For the keyboard rates to remain unchanged.

Actual behavior:
Keyboard rates are changed to 660 25.

To Reproduce:

$ xset r rate 300 50
$ swhks &
$ pkexec swhkd -c ~/.config/swhkd/swhkdrc
$ xset q
...
  auto repeat delay:  660    repeat rate:  25
...

[Shinyzenith]

Hi! thank you for the bug report
can you try the following?
git clone https://github.com/waycrate/swhkd/
cd swhkd
git checkout testing_auto_repeat
make setup
make
sudo make install

If it occurs even after that, we can try another approach of setting the autorepeat in the uinput device itself.

[loiccoyle]

No change :(

[Shinyzenith]

@vainiovano I think we need your assistance here 🙏🏽.

[vainiovano]

Those are Xorg's default key repeat settings. The settings are probably per-keyboard, which is why they change when switching to swhkd's virtual keyboard.

[Shinyzenith]

@vainiovano Is it possible to set it for the uinput device?

[Shinyzenith]

we could call the get autorepeat function and pass it to uinput ?

[vainiovano]

I think that evdev's autorepeat settings are per-fd, so Xorg can't read them, and I think that Xorg implements its own autorepeat itself anyway.

[vainiovano]

Hmm, from checking Linux' source code (and testing with evtest) it looks like repeat settings are global. I should probably remove setting them in swhkd. Anyway, they don't affect Xorg as it ignores repeat events.

[Shinyzenith]

Hmm, from checking Linux' source code (and testing with evtest) it looks like repeat settings are global. I should probably remove setting them in swhkd. Anyway, they don't affect Xorg as it ignores repeat events.

I guess we can try to call xset rate with a shell command after uinput creation?

[Shinyzenith]

if on x environment that is.

[Shinyzenith]

About this issue. @loiccoyle I was thinking of adding a flag to set custom repeat rates, which will just call xset after setting up the uinput device, what do you think?

[loiccoyle]

About this issue. @loiccoyle I was thinking of adding a flag to set custom repeat rates, which will just call xset after setting up the uinput device, what do you think?

I think that would be a reasonable work-around. Ideally, the user shouldn't have to worry about this at all though, imo.

[Shinyzenith]

About this issue. @loiccoyle I was thinking of adding a flag to set custom repeat rates, which will just call xset after setting up the uinput device, what do you think?

I think that would be a reasonable work-around. Ideally, the user shouldn't have to worry about this at all though, imo.

You are absolutely correct, I just don't have enough knowledge about the X11 protocol so I don't know how to do that automatically.
If you know any viable solutions then lmk!

[ajanon]

I am looking into how xset does it, based on the available source: xorg-xset.
There are many X11 bindings for Rust, I found x11rb to be well documented and it seems maintained.

It should not be too hard to communicate directly with the X11 server instead of calling xset.

I am not sure how to detect whether a server is running, though.

[Shinyzenith]

I am not sure how to detect whether a server is running, though.

What if we check if WAYLAND_DISPLAY is set or not? That way we can rule out wayland entirely.

[ajanon]

swhkd does not have access to the user's environment variables, though.
This is already proving to be tricky for this issue, as we cannot use the $DISPLAY environment variable.

[Shinyzenith]

Hm that is correct, what if we approach this in swhks? It has access to user env vars.

[ajanon]

We need the daemon online and the virtual input created before changing the keyboard rates.
While we could detect this in swhks, we also need to retrieve the previous rates, before swhkd has created the virtual device. I don't see how we could do that reliably as we have no control over which binary is started first.

Could we find a way for swhks to send environment variables values to swhkd? This would solve a number of issues and make it easier in many places.

[Shinyzenith]

Could we find a way for swhks to send environment variables values to swhkd? This would solve a number of issues and make it easier in many places.

I actually don't know why I didn't think of this earlier....this can fix a lot of things for us such as XDG_RUNTIME_DIR not being picked up on and defaulting to /run/user/$(PKEXEC_UID).

What if we had a initiation sequence between swhks and swhkd where the server syncs the state for the daemon? We could have some panic message from the daemon indicating that initiation must take place again in the case that swhkd has to be restarted after initiation has already taken place.

This sounds like a good plan, should we track this idea in a separate ticket?

[ajanon]

Yeah, this seems like a separate implementation plan.

Regarding the X11 keyboard rates: this seems trickier than I thought it would be. I will try to push a proof of concept later in the week.