Bug 13114 - server 1.4.1: Input Events Duplicated Across Different Windows
Summary: server 1.4.1: Input Events Duplicated Across Different Windows
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 13210 13223 13320 (view as bug list)
Depends on:
Blocks: xorg-server-1.4.1
  Show dependency treegraph
 
Reported: 2007-11-06 20:13 UTC by David Nusinow
Modified: 2007-11-20 08:00 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg.conf (3.50 KB, text/plain)
2007-11-06 20:14 UTC, David Nusinow
no flags Details
Logfile (31.84 KB, text/plain)
2007-11-06 20:15 UTC, David Nusinow
no flags Details
send correct events on autorepeat (909 bytes, patch)
2007-11-12 21:20 UTC, Peter Hutterer
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Nusinow 2007-11-06 20:13:29 UTC
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.
Comment 1 David Nusinow 2007-11-06 20:14:45 UTC
Created attachment 12376 [details]
xorg.conf
Comment 2 David Nusinow 2007-11-06 20:15:28 UTC
Created attachment 12377 [details]
Logfile
Comment 3 Michel Dänzer 2007-11-07 07:47:11 UTC
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

http://people.freedesktop.org/~daniels/no-core-xkb-actions.diff

but it makes the server abort with FatalError("Impossible keyboard event") on repeated key events.
Comment 4 David Nusinow 2007-11-07 17:35:55 UTC
(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
> 
> http://people.freedesktop.org/~daniels/no-core-xkb-actions.diff
> 
> 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.
Comment 5 Peter Hutterer 2007-11-12 19:14:10 UTC
*** Bug 13210 has been marked as a duplicate of this bug. ***
Comment 6 Peter Hutterer 2007-11-12 21:20:14 UTC
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).
Comment 7 Lukasz Krotowski 2007-11-13 15:40:17 UTC
(In reply to comment #6)
> Created an attachment (id=12490) [details]
> send correct events on autorepeat

Patch fixes the bug for me, thx.
Comment 8 Peter Hutterer 2007-11-15 22:15:07 UTC
*** Bug 13223 has been marked as a duplicate of this bug. ***
Comment 9 Daniel Stone 2007-11-17 13:45:34 UTC
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.
Comment 10 Daniel Stone 2007-11-20 08:00:32 UTC
*** Bug 13320 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.