No key repetition on sway 1.0-alpha.1 (Wayland)

[embik]

Which operating system does the issue occur on?
Gentoo Linux

If on linux, are you using X11 or Wayland?
Wayland

---

Hey there, I'm testing out sway's 1.0-alpha.1 release (first release based on wlroots) and it works quite well. Alacritty does start now too (its Wayland backend didn't work with sway 0.15). That being said, key repetition (holding down a key and repeating the key stroke) doesn't work which makes it barely usable without going mad (navigating files in vim is especially painful).

I'm not sure what information should be provided to dig into this issue. Running alacritty --print-events gives me these events when pressing and releasing the key x:

glutin event: WindowEvent { window_id: WindowId(Wayland(WindowId(139853503294496))), event: KeyboardInput { device_id: DeviceId(Wayland(DeviceId)), input: KeyboardInput { scancode: 45, state: Pressed, virtual_keycode: Some(X), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Wayland(WindowId(139853503294496))), event: ReceivedCharacter('x') }
glutin event: Awakened
glutin event: WindowEvent { window_id: WindowId(Wayland(WindowId(139853503294496))), event: KeyboardInput { device_id: DeviceId(Wayland(DeviceId)), input: KeyboardInput { scancode: 45, state: Released, virtual_keycode: Some(X), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }

To me it looks like glutin correctly recognizes key pressing and releasing. Is this an issue with glutin or Alacritty?

[emersion]

Note: see rust-windowing/winit#371

[chrisduerr]

This has also been mentioned in #97 but I don't see a problem with having a specific issue for it.

[embik]

@emersion checking winit slipped my mind, thanks for the information.

[staalmannen]

A bit off topic:

I am also running alacritty under sway 1.0 now. Do you also have a grey border around the window and a green, yellow and red square at the top right corner? If not, how did you get rid of it?
Running alacritty under xwayland did not have this and I had a proper border-less full-screen terminal.

[emersion]

If not, how did you get rid of it?

See Smithay/client-toolkit#1

I don't think it's possible to get rid of it yet. It's kind of hardcoded in wayland-window.

[elinorbgr]

Indeed, alacritty can specifically ask winit to not draw the borders (using set_decorate(false)), but that's about it until we implement the server decoration protocol support in smithay's client toolkit, yeah.

[darkanthey]

Key repetition it's the main blocker for me to switch to sway, alacritty for everyday usage.

[roji]

Same here, hope this gets resolved ASAP

[chrisduerr]

It has just been resolved in winit and will be published with the next update. I'd expect this to land with the #1403 patch.

[darkanthey]

I tried alacritty https://github.com/mkeeler/alacritty/tree/glutin-0.17-upgrade
It works like a charm. I hope this branch will merge with the main branch soon.

[Fierthraix]

@darkanthey I tried the fork you mentioned, as well as the version with gluting 0.18, and the issue persists with both for me.

[trimental]

@Fierthraix mm, that’s strange. I can’t really think what would cause this to only happen on only some devices as the only compositor specific behaviour is the delay and rate of the key repeats. What compositor are you using?

[sevagh]

FWIW, building from the glutin-0.17 branch mentioned above solved the issue for me: #1565

[kenan-rhoton]

I'm having this happen with Sway (the Wayland Window Manager), and I'm all for diving into the code if need be. Also, I've realized I don't actually press and hold keys that much 🤔

I would like this fixed, however, so are there any actions I could take to speed this up? I would be happy to come up with a PR if we know where the problem resides (I gather it's because we need to update the glutin dependency?), or to do some investigation if we're still not clear about where the problem lies.

[elinorbgr]

@kenan-rhoton this as been fixed upstream in rust-windowing/winit#628, and this issue should be resolved once #1403 is merged. Unless you already tried with this branch and the issue persists?

[kenan-rhoton]

I actually misread the comments about it, it solves it for me, what is blocking the merge?

[chrisduerr]

There was an upstream issue with winit/glutin which is currently blocking the PR. Once that is resolved it should be fairly quick until it can be merged. All of that can be read in #1403 in more detail.

[japrogramer]

+1