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

X11 implementation sometimes fails to process keyRelease events. #404

Closed
citizen-erased opened this Issue Jun 9, 2013 · 6 comments

Comments

Projects
None yet
3 participants
@citizen-erased

citizen-erased commented Jun 9, 2013

Issue

When SFML's key repeat is enabled on X11, WindowImplX11 sometimes doesn't process key released events. This seems to be because it erroneously discards them when trying to filter repeated events.

This causes the game to think a key is held down when in reality the key is released.

How To Reproduce

Hold a key down long enough to cause the OS to send key repeat events, and then release it. It's more likely to happen when your OS has a high key refresh set. Sometimes SFML will report the key as pressed when it's actually released.

Details

Replace 'examples/window/Window.cpp' and 'src/SFML/Window/Linux/WindowImplX11.cpp' with the files in this gist: https://gist.github.com/citizen-erased/5745591

I added some print statements to the window example and X11 implementation to show the issue. You can see it discards the final key up event from X11 (duplicate=1, discard=1) and SFML reports the key as pressed (down=1). The lines of dashes separate iterations of the main loop.

-----------------------
-----------------------
X11:  duplicate=0 [keycode=116 mode=up   time=21] discard=1
X11:  duplicate=1 [keycode=116 mode=down time=0] discard=0
SFML: [key=74 down=1]
-----------------------
X11:  duplicate=0 [keycode=116 mode=up   time=20] discard=1
X11:  duplicate=1 [keycode=116 mode=down time=0] discard=0
SFML: [key=74 down=1]
-----------------------
X11:  duplicate=0 [keycode=116 mode=up   time=20] discard=0
X11:  duplicate=1 [keycode=116 mode=down time=0] discard=0
X11:  duplicate=1 [keycode=116 mode=up   time=0] discard=1  <- This accidentally gets discarded
SFML: [key=74 down=0]
SFML: [key=74 down=1] <- and the game thinks the key is still down :(
-----------------------

Increasing the key repeat rate increases the chance of the issue happening. It happened maybe 5 - 10% of the time with the following settings. In a shell:

xset r rate 170 50

Note: This can also be reproduced at a lesser frequency with a more normal repeat rate.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jun 10, 2013

Member

What I don't understand is, how can you trigger two real events (key down and key up) with the exact same timestamp? Only repeated (fake) events are supposed to behave this way, if a human presses a key it will most likely last at least a few milliseconds before he releases it.

And can you do the same test with SDL? the hack I use in SFML is inspired by it, so it would be interesting to see if the hack itself is not reliable, or if it's only my implementation.

Member

LaurentGomila commented Jun 10, 2013

What I don't understand is, how can you trigger two real events (key down and key up) with the exact same timestamp? Only repeated (fake) events are supposed to behave this way, if a human presses a key it will most likely last at least a few milliseconds before he releases it.

And can you do the same test with SDL? the hack I use in SFML is inspired by it, so it would be interesting to see if the hack itself is not reliable, or if it's only my implementation.

@ghost ghost assigned LaurentGomila Jun 10, 2013

@vonj

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj Jun 10, 2013

Timer granularity?

Laurent Gomila notifications@github.com skrev:

What I don't understand is, how can you trigger two real events (key down and key up) with the exact same timestamp? Only repeated (fake) events are supposed to behave this way, if a human presses a key it will most likely last at least a few milliseconds before he releases it.

And can you do the same test with SDL? the hack I use in SFML is inspired by it, so it would be interesting to see if the hack itself is not reliable, or if it's only my implementation.


Reply to this email directly or view it on GitHub:
#404 (comment)

vonj commented Jun 10, 2013

Timer granularity?

Laurent Gomila notifications@github.com skrev:

What I don't understand is, how can you trigger two real events (key down and key up) with the exact same timestamp? Only repeated (fake) events are supposed to behave this way, if a human presses a key it will most likely last at least a few milliseconds before he releases it.

And can you do the same test with SDL? the hack I use in SFML is inspired by it, so it would be interesting to see if the hack itself is not reliable, or if it's only my implementation.


Reply to this email directly or view it on GitHub:
#404 (comment)

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jun 10, 2013

Member

Good point.

Member

LaurentGomila commented Jun 10, 2013

Good point.

@citizen-erased

This comment has been minimized.

Show comment
Hide comment
@citizen-erased

citizen-erased Jun 10, 2013

The output I posted only shows the last few iterations of the main loop. The real up and down events are seconds apart. The final X11 event, with a time different of 0, must be the real release event as it's preceded by the up and down event pair which is the OS sending key repeats.

Is it possible the real key up event occurs at the same time as the repeat events (at least according to the timer being used)?

I was unable to reproduce it with the latest version of SDL. I tried my SDL example on a different computer and was successfully able to reproduce it, so hopefully that rules out my hardware setup.

citizen-erased commented Jun 10, 2013

The output I posted only shows the last few iterations of the main loop. The real up and down events are seconds apart. The final X11 event, with a time different of 0, must be the real release event as it's preceded by the up and down event pair which is the OS sending key repeats.

Is it possible the real key up event occurs at the same time as the repeat events (at least according to the timer being used)?

I was unable to reproduce it with the latest version of SDL. I tried my SDL example on a different computer and was successfully able to reproduce it, so hopefully that rules out my hardware setup.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jun 11, 2013

Member

I was unable to reproduce it with the latest version of SDL. I tried my SDL example on a different computer and was successfully able to reproduce it, so hopefully that rules out my hardware setup.

So SDL has the same bug? Or did you mean "SFML" in your last sentence?

Member

LaurentGomila commented Jun 11, 2013

I was unable to reproduce it with the latest version of SDL. I tried my SDL example on a different computer and was successfully able to reproduce it, so hopefully that rules out my hardware setup.

So SDL has the same bug? Or did you mean "SFML" in your last sentence?

@citizen-erased

This comment has been minimized.

Show comment
Hide comment
@citizen-erased

citizen-erased Jun 11, 2013

So SDL has the same bug? Or did you mean "SFML" in your last sentence?

Sorry, I meant "SFML" in my last sentence.

citizen-erased commented Jun 11, 2013

So SDL has the same bug? Or did you mean "SFML" in your last sentence?

Sorry, I meant "SFML" in my last sentence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment