Bug 476106 - Control key with multiple keyboards does not work with evdev
Control key with multiple keyboards does not work with evdev
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-evdev (Show other bugs)
10
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-11 18:43 EST by Sam Creasey
Modified: 2009-10-08 02:52 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-08 02:52:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
same keyboard (4.00 KB, text/plain)
2008-12-21 23:44 EST, Sam Creasey
no flags Details
diff keyboard (4.00 KB, text/plain)
2008-12-21 23:45 EST, Sam Creasey
no flags Details
xevent dump with window focuses (8.00 KB, text/plain)
2008-12-22 08:24 EST, Sam Creasey
no flags Details

  None (edit)
Description Sam Creasey 2008-12-11 18:43:04 EST
Description of problem:

With multiple keyboard devices using evdev, pressing any key mapped to control on one keyboard does not modify a key pressed on another keyboard while control is held.  Keys mapped to mod1 do appear to work as Alt.  The problem occurs with many different keycodes mapped to "control" in xmodmap.

Using the kbd driver the control modifier works appropriately.  (Option "AutoAddDevices" "off")

Tested with a set of Kinesis USB foot pedals (primary use of a modifier on one keyboard device affecting another), but also reproducible with arbitrary pairs of USB keyboards (adding a PS/2 keyboard produced the same results).

The second (and later) key pressed while holding the key mapped to control is processed with the control modifier.


Version-Release number of selected component (if applicable):
xorg-x11-drv-evdev-2.0.7-3.fc10.x86_64

How reproducible:
Works Every Time(tm)

Steps to Reproduce:
1. Connect two keyboards while using the evdev driver
2. While olding control on one keyboard, press a key on the other
3. Watch the keypress get processed as if control were not pressed
Comment 1 Peter Hutterer 2008-12-21 20:44:12 EST
I just tried this on my F10 installation and it worked fine.
Please attach the xev output when you hold ctrl on one keyboard and press keys on the other.
Comment 2 Sam Creasey 2008-12-21 23:44:19 EST
attaching two xev dumps. They are, afaict, identical.  The first dump (same keyboard), consists of switching from the xev window to a terminal window, executing a ctrl-a followed by a ctrl-e.  (expected behavios was observed -- cursor went to the beginning of the line and back to the end).

The second attachement (diff keyboard) is basically indistunguishable from the xev output, however, the behavior was: switch from xev window to terminal window.  Hold ctrl key and press 'a'.  Watch 'a' get printed on command line.  press 'a' again with pedal held, and go to beginning of line.  release ctrl.  press ctrl, hold and press 'e'.  Watch 'e' get printed.  while ctrl is still held, press 'e' again, and watch cursor move to end of line.
Comment 3 Sam Creasey 2008-12-21 23:44:52 EST
Created attachment 327613 [details]
same keyboard
Comment 4 Sam Creasey 2008-12-21 23:45:18 EST
Created attachment 327614 [details]
diff keyboard
Comment 5 Peter Hutterer 2008-12-22 01:16:15 EST
if you switch away from xev, it won't receive the events anymore.

Please leave the xev window focused, and hit ctrl + a in all four combinations (kbd1 + kbd1, kbd1 + kbd2, kbd2+kbd1, kbd2+kbd2).
Comment 6 Sam Creasey 2008-12-22 08:24:48 EST
Created attachment 327638 [details]
xevent dump with window focuses

only had pedals+keyboard connected, so the key sequence is...  

hold ctrl on kbd1, press 'a' on kbd1, release all keys

hold ctrl on kbd2, press 'a' on kbd1, while ctrl is held, press 'a' again, release all kets

hold ctrl on kbd1, press 'e' on kbd1, release all keys

hold ctrl on kbd2, press 'e' on kbd1, while ctrl is held, press 'e' again.
Comment 7 Peter Hutterer 2008-12-22 17:22:41 EST
wait, I just noticed that "The problem occurs
with many different keycodes mapped to "control" in xmodmap."

If you do not have anything in your xmodmap, do the normal control keys work fine?
Comment 8 Sam Creasey 2008-12-22 17:50:29 EST
with no changes to xmodmap, the problem occurs.  I only brought xmodmap into the picture to make sure the issue was due to keys being mapped to "control", rather than the actual scancode of the left control key.
Comment 9 Peter Hutterer 2008-12-22 17:56:57 EST
weird, I just tested it on another F10 box and it works as well. what's the output of setxkbmap -print?
Comment 10 Sam Creasey 2008-12-26 22:45:53 EST
[pts/6]sammyville:~% setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "xfree86+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us"	};
	xkb_geometry  { include "pc(pc101)"	};
};
Comment 11 Sam Creasey 2008-12-26 22:48:41 EST
sorry, previous comment was with kbd driver.  evdev has:
[pts/0]sammyville:~% setxkbmap -print 
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(evdev)"	};
	xkb_geometry  { include "pc(pc104)"	};
};
Comment 12 Peter Hutterer 2009-10-08 02:52:35 EDT
This feature was disabled in server 1.6 (Fedora 11) in the X server. It got re-enabled with server 1.7 and is available again in the upcoming F12.

Since F10 will be retired soon and due to the huge number of changes to the input system this bug won't be fixed in F10.
F11 - as I said, it was an intentional upstream design (though a tad misguided).

Closing as NEXTRELEASE, this feature is back in F12.

Note You need to log in before you can comment on or make changes to this bug.