This is from server-1.4-branch from 11-5-2007. To reproduce:
1) Open up two xterms side by side using metacity as a window manager with focus follows mouse.
2) Have some sort of application in one terminal that will respond to a held down key. A good example is mutt with a mailbox full of mail (the selected message will change if you hold the up or down arrow key) or a shell with a command history.
3) Leave the cursor in the first terminal, and use alt-tab to switch to the second terminal.
4) Hold down a key (such as the up arrow). The event will go to both terminals, so, for example, the selected message will scroll up in mutt even though the focus is on the other terminal window.
I'm going to add this bug to the 1.4.1 tracker so it doesn't get lost, and I'll
also attach my xorg.conf and log.
Created attachment 12376 [details]
Created attachment 12377 [details]
It seems to affect just repeated key events here - they get delivered to the focused window and the one below the pointer (so repeat speed appears to double when they coincide). Daniel Stone asked me to try
but it makes the server abort with FatalError("Impossible keyboard event") on repeated key events.
(In reply to comment #3)
> It seems to affect just repeated key events here - they get delivered to the
> focused window and the one below the pointer (so repeat speed appears to double
> when they coincide). Daniel Stone asked me to try
> but it makes the server abort with FatalError("Impossible keyboard event") on
> repeated key events.
Yes, I get the exact same results. The bug only happens with repeated key events, and the patch causes the same crash for me.
*** Bug 13210 has been marked as a duplicate of this bug. ***
Created attachment 12490 [details] [review]
send correct events on autorepeat
The reason for this is a bit complicated, here's an attempt of an explanation.
XI devices have separate focus settings to core devices. A WM that sets the focus using XSetInputFocus only sets it for the core keyboard, not for all the XI devices.
In the autorepeat handler, we'd send down a core KeyPress/KeyRelease event for the device registered. This would be alternating the core keyboard and the actual device that generated the event. The former is all nice and goes to the right window, the latter however is by default set to PointerRootWin. So when the event is processed, it goes to the sprite window, causing the repeats to occur in a second window.
The solution is fairly simple: the XI device shouldn't actually generate the core event in the first place. So in the repeat handler, we check for the type of the device and create KeyPress or DeviceKeyPress accordingly. That means that XI events are still delivered to the sprite window but that's how the server has always behaved (and nobody cares about XI events anyway).
(In reply to comment #6)
> Created an attachment (id=12490) [details]
> send correct events on autorepeat
Patch fixes the bug for me, thx.
*** Bug 13223 has been marked as a duplicate of this bug. ***
I was hoping to avoid the core keyboard generating repeat events at all, but this is a good minimal fix for 1.4.x. Applied with some minor cleanups -- thanks.
*** Bug 13320 has been marked as a duplicate of this bug. ***