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

Key repeat rate on Linux, Wayland, Sway is interpreted inversely #777

Closed
e00E opened this issue Jan 26, 2019 · 7 comments
Closed

Key repeat rate on Linux, Wayland, Sway is interpreted inversely #777

e00E opened this issue Jan 26, 2019 · 7 comments
Labels
B - bug Dang, that shouldn't have happened DS - wayland

Comments

@e00E
Copy link

e00E commented Jan 26, 2019

This is a copy of alacritty/alacritty#2041 . I initially reported it there but was pointed to testing it with winit directly.


I am using Linux with Wayland with Sway.

I am setting the key repetition rate in my sway config. Per man 5 sway-input:

input <identifier> repeat_rate <n>
Sets the key repeat rate in number of keypresses per second.

Alacritty is interpreting this value the wrong way.

When set to 1 I should observe one repetition per second and when set to 1000 I should observe 1000 repetitions per second. This works correctly in the browser I am typing this from (Firefox).

Alacritty seems to interpret the value as the number of milliseconds between repetitions giving me a lot of repetitions per second in the first case and 1 in the second case.

$ alacritty --version
alacritty 0.2.7
sway --version
sway version 1.0-beta.2-274-g5f45a4bb (Jan 25 2019, branch 'makepkg')

I can reproduce this problem with winit directly.

As explained in #776 (comment) I am using a https://github.com/tomaka/glutin example.

I am holding down the f key and from the console output I can see that the event appears with the wrong rate as described above.

WindowEvent { window_id: WindowId(Wayland(WindowId(94063627530576))), event: KeyboardInput { device_id: DeviceId(Wayland(DeviceId)), input: KeyboardInput { scancode: 33, state: Pressed, virtual_keycode: Some(F), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
WindowEvent { window_id: WindowId(Wayland(WindowId(94063627530576))), event: ReceivedCharacter('f') }
WindowEvent { window_id: WindowId(Wayland(WindowId(94063627530576))), event: KeyboardInput { device_id: DeviceId(Wayland(DeviceId)), input: KeyboardInput { scancode: 33, state: Pressed, virtual_keycode: Some(F), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
WindowEvent { window_id: WindowId(Wayland(WindowId(94063627530576))), event: ReceivedCharacter('f') }
Awakened
WindowEvent { window_id: WindowId(Wayland(WindowId(94063627530576))), event: KeyboardInput { device_id: DeviceId(Wayland(DeviceId)), input: KeyboardInput { scancode: 33, state: Pressed, virtual_keycode: Some(F), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
WindowEvent { window_id: WindowId(Wayland(WindowId(94063627530576))), event: ReceivedCharacter('f') }
Awakened
...
@e00E
Copy link
Author

e00E commented Jan 27, 2019

Found the problem in client-toolkit. Working on PR.

@trimental
Copy link
Contributor

Yeah this is my bad, I read the wayland documentation wrong since the key repeat delay is in milliseconds. This should be fixed by Smithay/client-toolkit#62

@trimental
Copy link
Contributor

At the exact same time, what are the chances ahah.

@e00E
Copy link
Author

e00E commented Jan 27, 2019

Oh, you have already done it, great!

@e00E e00E closed this as completed Jan 27, 2019
@francesca64 francesca64 added B - bug Dang, that shouldn't have happened DS - wayland labels Jan 28, 2019
@e00E
Copy link
Author

e00E commented Mar 5, 2019

Would it be possible to update the client toolkit dependency from 0.4 to the current 0.6 which includes this bugfix?

@e00E e00E reopened this Mar 5, 2019
@Osspial
Copy link
Contributor

Osspial commented Mar 5, 2019

cc @vberger

@elinorbgr
Copy link
Contributor

This update is contained in the eventloop-2.0 refactor. Backporting the update to master branch would be a significant amount of work (it implies an upgrade of wayland-client, which was very largely breaking) that I am not willing to do a second time.

However, I released SCTK 0.4.5 containing this fix, cargo update should bring it to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B - bug Dang, that shouldn't have happened DS - wayland
Development

No branches or pull requests

5 participants