key repeat -- how to turn this off?

[Johnrobmiller]

I am speaking of the ElementState module. For example, ElementState::Pressed. The docs only mention "Press" and "Release" and give no further information.

There are many issues opened up requesting this feature dating from years back. I don't think it's worth it for anybody (including myself) to spend, for example, 30 minutes browsing through all of what there is to find on this topic just to get a simple "no" or "yes, here is how it is done."

So, let's keep this discussion simple. How do you turn off key repeat? Let's keep our answers short. This will help us all find out what we need without digging through long threads.

I'll mention this to try and be helpful to other people -- if it is impossible, then it is not too hard just to make a variable such as "was_up_key_press_counter" and reset it to 0 when the key is released. This is only one of many possible workarounds.

EDIT: Going to give some honest feedback, if there truely is no way to detect or turn off key repeat, then I think winit should probably get there stuff together because this is such an obvious and needed feature 😉 It makes me think that the people who made this library have not actually used it to make real programs, or the programs they make are very narrow in type (I am making a game with a custom engine, so that is my perspective), and they don't actually have any idea what their product needs to do to be functional.

[kchibisov]

https://docs.rs/winit/latest/winit/event/struct.KeyEvent.html#structfield.repeat

probably get there stuff

I'd suggest you to learn how to communicate, We don't owe you anything, we're working on it in our free time for nothing. It's not the first time you communicate and try to straight offense people.

[Johnrobmiller]

You think I'm trying to offend, you? I'm trying to help you.

I know you don't owe me anything. I don't owe you anything either, but I actually trying to help you. I am doing free QA for your product. Think about that. If I bring awareness to an issue, as QAers do, then that is valuable, and I am giving that to you for free. Please accept it, because I actually want to see this product get better.

Pointing out genuine problems is NOT being offensive. If you are offended when problems are pointed out to you, then you are a fragile person with a fragile ego, and that is a weakness. You can't get better and grow without humility, and twice now I've seen you lose your temper whenever someone says something negative about you or something you work on, which tells me you might not be a particularly humble person who can integrate criticism and negative feedback into their life. That is far worse then not providing a way to disable key repeat on the winit crate.

But regarding the original post, can it be done? It would be helpful if people could get a straitforward yes or no answer about this.

[madsmtm]

Moderation notice: Comments here are bordering on personal attacks. I would like to remind both parties of the Rust Code of Conduct, to please remain courteous and on topic, and to remember to look past possible language barriers. We are all volunteers, and all want the best for the project!

---

Responding to the actual question about key repeats: No, you cannot turn key repeat off, but you can ignore the event yourself, by only responding to the event if the repeat field is false.

I believe this should yield effectively the same thing, but if there is some reason why that is not true, please try to explain why that is so? Ideally with code, that makes it easier to discuss.

[kchibisov]

You think I'm trying to offend, you? I'm trying to help you.

I pointed you to the field showing you that you can identify that the key is repeat or not so you can ignore them? Like I if you don't understand that from the link I've posted and still try to ask me how it should be done I'm not sure how to help you.

[John-Nagle]

There's a legit question here. I found this because I have a problem where holding an arrow key down for a long time in a game-type program sometimes causes the action to continue for seconds after key release.

I'm ignoring events where input.repeat is set. But I'm not sure that's the correct action. Could that cause me to miss a key-up event?

[madsmtm]

Ignoring events where input.repeat is set is the correct behaviour. I've submitted #3538 to improve the documentation on this, please give your suggestions there!

[John-Nagle]

Hm. I'm getting long delays (seconds) on key-up after a long hold from somewhere. Key-down works fine. This is on Linux/X11. It's almost like all the queued repeats take place and then a key-up is sent.

[kchibisov]

if you render on each key press at may queue if you batch correctly it'll work fine.

[John-Nagle]

I render at AboutToWait only.

[madsmtm]

I render at AboutToWait only.

Which is wrong, you should render inside WindowEvent::RedrawRequested (and probably call window.request_redraw() inside the same).

[John-Nagle]

Sorry, I meant that I render at RedrawRequested, but I call RequestRedraw only at AboutToWait.

Winit docs say to call RequestRedraw at the end of the redraw in RedrawRequested, but that behaves terribly. Worst case is Windows executables under Wine, where every key is delayed about 3 seconds. X11 on Linux is a big sluggish.

Winit doesn't really manage this; it passes the buck to the underlying platform. Wine has its own event loop, and it's not a good one.

[kchibisov]

If you don't handle it it doesn't mean that it's not going... Just drop all repeat events if you don't care about key repeat.

[cfagot]

That's not the issue. The issue is that key repeat events are buffered, for as much as a second or so, if going through the WindowEvent::KeyboardInput. I can ignore all the repeat keys but I won't get a key up until they are all processed half a second later (and no, it's nothing to do with me not processing them since this is 30 frames or so later). On the other hand, the DeviceEvent::Key events happen immediately (which should be taken as evidence that it isn't related to how John-Nagle and myself are processing the events).

I understand that winit isn't somehow buffering these keys and that this is a platform layer issue (it happens on x11, I'm not sure about other platforms). I'm more concerned that wayland isn't producing the DeviceEvent::Key since that is the work around for the buffering issue.

I'm about to be AFK, but if this isn't clear I can create a simple app to demonstrate.

[kchibisov]

Unless you literally block the event loop every time you get a key repeat event it shouldn't happen, since otherwise I'd at least see it once myself given that I use winit daily and have relatively high refresh rate which stops starts/stops nearly instantly.

[kchibisov]

DeviceEvent::Key doesn't exists on Wayland because Wayland has no device events at all. In general using device key events is error prone, since you can not type with them and they don't account for the layouts at all.

[cfagot]

Ok, I'll work on a repro case so we can get on the same page here. Probably won't be till tomorrow.

Thanks for confirming the wayland behavior. I was assuming it was something like that. However, note that layout isn't really an issue for me since this is for game controls not text input. Text input would still use the normal window event path. Similarly I recall someone mentioning a similar issue with mouse input -- the device event keeps working event when mouse goes outside the window, which is the behavior they needed. So it's not the case that window event good, device event bad. There are different use cases.

[John-Nagle]

I can create a simple app to demonstrate.

I'd appreciate that. I'm seeing this in a full-scale game, with the whole Winit/egui/rend3/Vulkan stack running.
A simple standalone repro would help.

[cfagot]

Well, the story is more interesting than I thought.

My idea of making a simple app to show the repeat keys buffering didn't work -- or rather the app did work in that it didn't have a problem with buffering.

That made me go back to my app that had the issue (this was back in git history of an app a couple months back which I had since converted to using device events). At the time the app was based on winit 0.29.15.

I can confirm that window events for this app cause buffering of repeat keys while device events do not. This is on x11.

But when I change from FIFO to Immediate presentation mode the issue goes away (I render at 30 fps in FIFO on this monitor).

After putting in some print lines there was consistently only 1 repeat key event per frame. Not sure of the reason for this. Even when I increased the repeat rate to be only 1 ms between repeats I only got one repeat key per frame (in FIFO). This might be because I'm spending so much time waiting on vsync, which is what krill suggested.

That being said, none of this happens on wayland. Even with 40 fps vsync (different machine) and 1 ms per repeat key I did not see any buffering of repeat keys.

This makes me think there is something a little funky with x11 and that this isn't just an effect of vsync (or slow render times).

So anyway, I don't think the repeat key buffering is good behavior, but I'm not sure what winit can do about it. My work around is to use WindowEvent::KeyInput events for everything but X11, where I'll use DeviceEventK::Key (for key presses, not text input).

One thing I'm curious about is whether some of this can be ameliorated by timing the render call closer to vsync. That's an advanced technique that shouldn't be required (in my view)to get decent key repeat behavior, but it would at least be a solution. I don't think rendering in a thread solves the issue because in the end it's waiting for vsync that is the issue, and that has to happen in the main thread as far as I know.

Oh, and I guess you can always turn off or down key repeat in the settings and advise x11 users to do the same.

[cfagot]

Not sure why you think I'm drawing for each key press. As I mentioned above if I render only after 30 ms, thus avoiding vsync but continuously responding to the event loop in the meantime, I still only get one repeat key per frame even when repeat rate is set at one key per ms. When I stop pressing the key it basically keeps reading one key per frame for thousands of keys. I don't see how the keys could be queueing up on the event loop and me missing them (which is what I think you are saying) if I am constantly running the event loop for 30 ms between renders. I'll work on a test case since I think that will be helpful no matter what.

[kchibisov]

Then using DeviceEvent shouldn't solve anything, yet you say that it solves?

[cfagot]

Then using DeviceEvent shouldn't solve anything, yet you say that it solves?

Yeah, I think that's the right question, but I don't follow your "gotcha". If all the events were queued up by time with the release events from device and window right next to each other then using DeviceEvents certainly wouldn't help. So that they do help means this isn't happening. And let me tell you, it very clearly isn't happening.

Here is the app I've been promising that would demonstrate what is going on:

https://github.com/cfagot/test_winit_event/tree/main

It is using the update method you suggested (render in request render and requesting a new render a the end of that). It forces a 10 ms delay in the render to simulate a 100 fps app (you can play with that number, but 10 ms delay should be considered reasonable, I think).

I render 4 triangles. The top row controlled by key events the bottom by mouse events. The left column by device events and the right column by window events. It also outputs to the console the relevant events, including the top and bottom of a single iteration of the event loop. This clearly demonstrates the issue that myself and other people in this thread see. In particular, if you are on x11 keyboard device events work fine but the window variant has buffering issues. The mouse events working fine no matter what (even with 1 second render time) demonstrating that it isn't somehow the app hogging the event loop but x11 not feeding the event loop.

I have a feeling this is just a limitation of x11 (like maybe there is an expensive back and forth protocol to get the next key which limits winit to getting one key per time through the event loop*). If that's so there is a work-around (use device events for most platforms -- they are snappier even besides the key repeat issue -- and window key evens for wayland). But if it's fixable, I think it would be a good idea.

*actually, even that is fixable with another thread.

ps. @John-Nagle maybe you can test out this app (maybe play with some parameters) and let me know if it explains what you are experiencing.

Krill - I do appreciate your time on this. But I'm convinced you are over-looking what is going on. I'm open to the idea that I don't know what i don't know though, so happy to continue this discussion if you don't feel it is a waste of your time.

[kchibisov]

But you don't drop the repeat events as it was told multiple times in this issue, so they match the device events branch like it was told in this issue on how to avoid that.

If you simply ignore all events which marked with repeat they should be on-par with what you get via the device branch.

There could be a possibility that all events are just delayed for whatever reason for you which could be checked with x11trace, just in case could you test on something like i3/dwm without anything running that could touch input?

[cfagot]

But you don't drop the repeat events as it was told multiple times in this issue, so they match the device events branch like it was told in this issue on how to avoid that.

If you simply ignore all events which marked with repeat they should be on-par with what you get via the device branch.

That's not true at all. I've understood about repeat events the entire time and haven't been ignoring you. The repeat events are implicitly ignored because the app is tracking whether the key is pressed. You can only turn the light on once. The key is that the release event is delayed till after all the pressed events occur no matter how I respond to them.

There could be a possibility that all events are just delayed for whatever reason for you which could be checked with x11trace, just in case could you test on something like i3/dwm without anything running that could touch input?

I'll look into it. I guess what seems more important to me is if other people can replicate what I'm seeing on x11. I see it on two machines (with different refresh rates). And if I switch to wayland it goes away.

[John-Nagle]

@cfagot I need to get to this. Thanks.

We need to figure out what best practice for games is.

[cfagot]

I need to look into how the repeat goes when forwarding to ibus works

It's not just repeat though. If you mash that keyboard you can still only get one key per time through single_iteration method.

BTW, one other platform difference I noticed is that wayland doesn't seem to honor repeat (but can handle multiple keys between new_events and about_to_wait if you mash the keyboard).

I'll submit a ticket trying to lay everything out.

[kchibisov]

BTW, one other platform difference I noticed is that wayland doesn't seem to honor repeat (but can handle multiple keys between new_events and about_to_wait if you mash the keyboard).

It really depends how you do that, but Wayland works correctly, at least you can try to repro with alacritty, maybe you're doing something different, but for me the repeat in it works like in any other application.

[cfagot]

Ok, new issue submitted: 3815

[cfagot]

It really depends how you do that, but Wayland works correctly, at least you can try to repro with alacritty, maybe you're doing something different, but for me the repeat in it works like in any other application.

Oh, that one is a little strange. If I turn the repeat rate down to normal levels I do get the repeat events. But when I turn it all the way to max (1 key/ms) it does not emit the repeat events, just a single pressed and single released. Maybe wayland understands the absurd.

[kchibisov]

I mean, all of that is handled inside the winit in seat/keyboard.rs, so it's not that hard to figure what it does.