We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

This is working correctly here, both with the 2.0.5 release, and the latest in Mercurial. I tried this on X11.

If you hold down the key, we'll send multiple KEYDOWN events, though; is that what you're seeing?

--ryan.

No, the issue I'm describing occurs with very brief presses of the key (well before the auto-repeat kicks in).

I wrote the attached program and tested it when linked with SDL 2.0.4 and 2.0.5, and the behavior is definitely different- on 2.0.5, the keypress event shows up a second time during a subsequent SDL_PollEvent(), no matter how quickly you try to press and release the key, whereas on earlier versions, the event only appears once during the first SDL_PollEvent() call.

I could probably dig around in SDL2 myself to try and debug the issue from my end if it turns out you're unable to reproduce the issue on your end. I'm running Ubuntu 14.04 (although it is somewhat modified from the base install, for example with SDL2 compiled from source rather than installed from Ubuntu's repositories).

(In reply to sn0w75 from comment #2)
> running Ubuntu 14.04 (although it is somewhat modified from the base

I tried on 16.04 and had no regression; is this just a stock install of 14.04 with Unity, or are you running a different Desktop Environment like Gnome, KDE, some other window manager? I can try to reproduce here.

Failing that, we'll need to either get some printf() calls in SDL to get more info, or have you step through in a debugger, or something.

--ryan.

I'm still using Unity on this install, but I can't really call it a stock install, either- between the use of large PPAs (for example: https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-staging ) and building several packages from source myself, this is a pretty hacky system I'm running, unfortunately.

I should be able to write in some printf() calls or stepping through a debugger if we need to. If you want me to try on a stock Ubuntu 14.04 install myself...I don't have DVDs handy or virtual machines setup, so I would prefer to avoid that if possible.

(In reply to sn0w75 from comment #4)
> I should be able to write in some printf() calls or stepping through a
> debugger if we need to. If you want me to try on a stock Ubuntu 14.04
> install myself...I don't have DVDs handy or virtual machines setup, so I
> would prefer to avoid that if possible.

If you're willing to try, go for it!

This is where we handle key presses from X11:

    https://hg.libsdl.org/SDL/file/f0ddcc015995/src/video/x11/SDL_x11events.c#l762

They enter the SDL event queue in the SDL_SendKeyboardKey() function, which is called down there.

A likely culprit is that code around "handled_by_ime", since that's talking about duplicates.

It's unlikely an existing SDL event is failing to remove from the queue; it's way more likely that we generated more SDL_KEYDOWN events than we should have.

--ryan.

> If you're willing to try, go for it!

...and if you get stuck, no worries, just let us know how far you got and we'll try to figure out what to do next. Until then: we're all cheering for you!  :)

--ryan.

For starters, running the test program with DEBUG_XEVENTS enabled on SDL 2.0.5, I got the following:


window 0x2632800: PropertyNotify: XdndAware changed time=114428690
{ BITMAP }
window 0x2632800: PropertyNotify: WM_NAME changed time=114428690
{ "SDL2 Regression Bug" }
window 0x2632800: PropertyNotify: _NET_WM_NAME changed time=114428690
{ "SDL2 Regression Bug" }
window 0x2632800: Unhandled event 21
window 0x2632800: ConfigureNotify! (position: 65,24, size: 800x600)
window 0x2632800: ConfigureNotify! (position: 65,24, size: 800x600)
window 0x2632800: Expose (count = 0)
window 0x2632800: PropertyNotify: _NET_WM_STATE changed time=114428698
window 0x2632800: FocusIn!
window 0x2632800: Dispatching FocusIn
window 0x2632800: WM_TAKE_FOCUS
window 0x2632800: PropertyNotify: _NET_WM_DESKTOP changed time=114428699
{ 0 }
window 0x2632800: PropertyNotify: WM_STATE changed time=114428699
Unknown type: 368 (WM_STATE)
window 0x2632800: ConfigureNotify! (position: 66,52, size: 800x600)
window 0x2632800: Expose (count = 1)
window 0x2632800: Expose (count = 0)
window 0x2632800: PropertyNotify: _NET_WM_ALLOWED_ACTIONS changed time=114428701
{ _NET_WM_ACTION_MOVE _NET_WM_ACTION_RESIZE _NET_WM_ACTION_STICK _NET_WM_ACTION_MINIMIZE _NET_WM_ACTION_MAXIMIZE_HORZ _NET_WM_ACTION_MAXIMIZE_VERT _NET_WM_ACTION_FULLSCREEN _NET_WM_ACTION_CLOSE _NET_WM_ACTION_SHADE _NET_WM_ACTION_CHANGE_DESKTOP _NET_WM_ACTION_ABOVE _NET_WM_ACTION_BELOW }
window 0x2632800: PropertyNotify: _NET_FRAME_EXTENTS changed time=114428701
{ 1 0 1 0 }
New _NET_FRAME_EXTENTS: left=1 right=1, top=28, bottom=1
window 0x2632800: PropertyNotify: _NET_WM_STATE changed time=114428730
{ _NET_WM_STATE_FOCUSED }
window 0x2632800: PropertyNotify: _NET_WM_STATE changed time=114428731
{ _NET_WM_STATE_FOCUSED }
window 0x2632800: PropertyNotify: _NET_WM_ICON_GEOMETRY changed time=114428920
{ 0 0 0 0 }
window 0x2632800: PropertyNotify: _NET_WM_ICON_GEOMETRY changed time=114429630
{ 5 0 933 0 }
LEFT KEY PRESSED DOWN
window 0x2632800: KeyPress (X11 keycode = 0x71)
window 0x2632800: updating _NET_WM_USER_TIME to 114429638
LEFT KEY PRESSED DOWN
window 0x2632800: PropertyNotify: _NET_WM_USER_TIME changed time=114429640
{ 114429638 }
window 0x2632800: KeyRelease (X11 keycode = 0x71)



Running with SDL 2.0.4, I get the following:
window 0x2633fe0: PropertyNotify: XdndAware changed
{ BITMAP }
window 0x2633fe0: PropertyNotify: WM_NAME changed
{ "SDL2 Regression Bug" }
window 0x2633fe0: PropertyNotify: _NET_WM_NAME changed
{ "SDL2 Regression Bug" }
window 0x2633fe0: PropertyNotify: _NET_WM_ALLOWED_ACTIONS changed
{ _NET_WM_ACTION_MOVE _NET_WM_ACTION_RESIZE _NET_WM_ACTION_STICK _NET_WM_ACTION_MINIMIZE _NET_WM_ACTION_MAXIMIZE_HORZ _NET_WM_ACTION_MAXIMIZE_VERT _NET_WM_ACTION_FULLSCREEN _NET_WM_ACTION_CLOSE _NET_WM_ACTION_CHANGE_DESKTOP _NET_WM_ACTION_ABOVE _NET_WM_ACTION_BELOW }
window 0x2633fe0: Unhandled event 21
window 0x2633fe0: ConfigureNotify! (position: 65,24, size: 800x600)
window 0x2633fe0: ConfigureNotify! (position: 65,24, size: 800x600)
window 0x2633fe0: Expose (count = 0)
window 0x2633fe0: PropertyNotify: _NET_WM_STATE changed
window 0x2633fe0: FocusIn!
window 0x2633fe0: Dispatching FocusIn
window 0x2633fe0: PropertyNotify: _NET_WM_DESKTOP changed
{ 0 }
window 0x2633fe0: PropertyNotify: WM_STATE changed
Unknown type: 368 (WM_STATE)
window 0x2633fe0: ConfigureNotify! (position: 66,52, size: 800x600)
window 0x2633fe0: Expose (count = 1)
window 0x2633fe0: Expose (count = 0)
window 0x2633fe0: PropertyNotify: _NET_WM_ALLOWED_ACTIONS changed
{ _NET_WM_ACTION_MOVE _NET_WM_ACTION_RESIZE _NET_WM_ACTION_STICK _NET_WM_ACTION_MINIMIZE _NET_WM_ACTION_MAXIMIZE_HORZ _NET_WM_ACTION_MAXIMIZE_VERT _NET_WM_ACTION_FULLSCREEN _NET_WM_ACTION_CLOSE _NET_WM_ACTION_SHADE _NET_WM_ACTION_CHANGE_DESKTOP _NET_WM_ACTION_ABOVE _NET_WM_ACTION_BELOW }
window 0x2633fe0: PropertyNotify: _NET_FRAME_EXTENTS changed
{ 1 0 1 0 }
window 0x2633fe0: PropertyNotify: _NET_WM_STATE changed
{ _NET_WM_STATE_FOCUSED }
window 0x2633fe0: PropertyNotify: _NET_WM_STATE changed
{ _NET_WM_STATE_FOCUSED }
window 0x2633fe0: PropertyNotify: _NET_WM_ICON_GEOMETRY changed
{ 0 0 0 0 }
window 0x2633fe0: PropertyNotify: _NET_WM_ICON_GEOMETRY changed
{ 5 0 933 0 }
window 0x2633fe0: KeyPress (X11 keycode = 0x71)
LEFT KEY PRESSED DOWN
window 0x2633fe0: KeyRelease (X11 keycode = 0x71)
window 0x2633fe0: KeyPress (X11 keycode = 0x9)


Oddly, in SDL 2.0.4 the escape key press (keycode 0x9) is printed before the program closes, but in 2.0.5, it doesn't get printed.

At any rate, X11 seemed to be only producing a single KeyPress event in both 2.0.4 and 2.0.5, yet two KeyPress were showing on two separate calls of SDL_PollEvents() for 2.0.5. So I looked a bit further downstream as you suggested.

I bugged all the SDL_SendKeyboardKey(SDL_PRESSED, ...) calls with printf lines, and sure enough, SDL_SendKeyboardKey(SDL_PRESSED, ...) is getting called twice in 2.0.5.
First at line 575, then again on line 795.
Sounds like your hunch about handled_by_ime was right on the mark ;)

Let me know if there's anything else I can do to help- I'm not familiar with the SDL2 codebase, so it's not immediately obvious to me how this bug ought to be fixed (beyond the idea that some kind of conditional needs to be added to L794 so that it doesn't re-send the keypress).

Alex, can you quickly take a look at this for the SDL 2.0.6 release?

I have just tested both the test/checkkeys program, and the attached test case against 3 builds of SDL hg: default (ime+ibus enabled), --disable-ibus, and --disable-ibus --disable ime.

For each of these, I tested with ibus-daemon not running, running, and running with --xim. And for each of those cases, I also tested with XMODIFIERS either unset, or set to @im=ibus.

Unfortunately, in none of these 18 configurations was I able to reproduce the issue.

To debug further, I would need to know from sn0w75:
1) Which version of SDL 2.0.5 are you using? Please test the latest one from "hg clone http://hg.libsdl.org/SDL" (Don't forget to either build your program statically with the new library, or set LD_LIBRARY_PATH to build/.libs/)
2) How the ime/ibus stuff is configured when you build SDL (there will be a printout after running ./configure showing either YES or NO for both ibus and ime)
3) If ibus-daemon is running, and if so with --xim or not (ps aux | grep ibus)
4) what the XMODIFIERS environment variable is set to. (echo $XMODIFIERS)
5) XKB settings (xprop -root | grep XKB)

Thanks.

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.