Description of problem: I've been using "keycode 135 = Mode_switch" in my ~/.xmodmap for years, to change my "menu" key into something useful. Starting sometime fairly recently (not sure exactly; sorry) occasionally (no repeatable case, but happens regularly enough to be annoying), the mode_switch gets stuck in on, such that pressing the key and a letter gives its normal version rather than its mode_switch version. (It's as if the equivalent of caps-lock for mode_switch is on.) There doesn't seem to be any cure but hitting mode_switch a bunch of times and other random typing -- eventually it goes off again. Version-Release number of selected component (if applicable): Possibly xorg-x11-drv-evdev-2.3.0-1.fc12.x86_64. I'm just blaming evdev because it's convenient -- could be a lot of things, I suppose.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #0) > Possibly xorg-x11-drv-evdev-2.3.0-1.fc12.x86_64. I'm just blaming evdev because > it's convenient -- could be a lot of things, I suppose. Let's try to blame Xserver itself :) (it doesn't matter that much because issues of input go to Peter anyway). Please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 378349 [details] dmesg output
Created attachment 378350 [details] Xorg.0.log
Attached requested logs. This is on my Rawhide box. It also happens on my F12 system at home, which has a different radeon card and generally different hardware overall. I can attach that if you think it might be helpful. I think *maybe* the problem is related to the key _next_ to this one; I've defined that to be Multi_key, and it may be related to hitting that accidentally in some way. I still can't reproduce _on purpose_ though. (But it does happen once every couple of days.)
Created attachment 378354 [details] xmodmap I must add that the ability to type hearts and flowers was added at the request of my 4-year-old daughter. Just sayin'.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This is still happening, by the way. And I removed the definition for Multi_key, so that's _not_ it.
This is still happening. It is very annoying. I attached the requested information -- see above. Anything else I can do to help get this resolved? I know this is far from critical path, but it's a very annoying regression.
✶°† ™♥i★ i★ ★™ill ♥a☠☠€ñiñℊ wi™♥ ¢urr€ñ™ raw♥i°€• ✓€ry aññ°yiñℊ• Añy ★uℊℊ€★™i°ñ★⁄ Añy ★uℊℊ€★™i°ñ★ a™ all⁄
some beautiful hearts in there though ;) please run "xkbcomp -xkb $DISPLAY -" when the problem doesn't occur and after it occurs. Does the diff show anything? If so, then we have some corruption in the server. Attach the file here please too, I want to have a look at the layout. what does xev show once the problem occurs for key presses?
Of course, after that last message, it didn't happen for a while. But now it is. I'll post the xkbcomp output after it clears up; here's the xev output for pressing the s key: KeyPress event, serial 34, synthetic NO, window 0x2e00001, root 0xfb, subw 0x0, time 2996500443, (158,13), root:(283,306), state 0x2010, keycode 39 (keysym 0x1002605, U2605), same_screen YES, XLookupString gives 3 bytes: (e2 98 85) "★" XmbLookupString gives 3 bytes: (e2 98 85) "★" XFilterEvent returns: False KeyRelease event, serial 34, synthetic NO, window 0x2e00001, root 0xfb, subw 0x0, time 2996500539, (158,13), root:(283,306), state 0x2010, keycode 39 (keysym 0x1002605, U2605), same_screen YES, XLookupString gives 3 bytes: (e2 98 85) "★" XFilterEvent returns: False (A bit later) Okay, yeah, back to normal now. xkbcomp output is unchanged. I'll attach that.
Created attachment 410301 [details] xkbcomp -xkb $DISPLAY -
Just happened to me again on my newly-reinstalled (fresh; not upgrade) F13 laptop. (Same .xmodmap file.) Graphics card in this one is "Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller rev 7", so I think we can rule out ATI as the problem.
You may try to reproduce bug holding down the Mode_switch key, so it starts to "repeat" mode switching regardless of setting for autorepeat option (xset -r). During this, "state" field in xev cycles +0000 +2000 +4000 (with numlock active it leads to 0x10 0x2010 0x4010 states). If you depress it in correct time, all keys and combinations work well again. Normal behaviour of M_s key seen as +2000 in active state (pressed), +0000 inactive (depressed).
Created attachment 452610 [details] xmodmap to reproduce probla With the attached modmap you can easily reproduce this problem. It uses the space bar as a modifier. Note: You might hate this layout, prepare your own xmodmap on a different console to switch back! Steps to reproduce: 1. xmodmap .Xmodmap 2. press down 'f' key (do not release it). 'f' appears multiple times 3. press down space bar (do not release it). 'f' stops appearing 4. release 'f' key 5. release space bar 6. you now have a 70% chance that your keyboard is out of sync: Press 'f' key and '(' appears These instructions work almost always for me to get the keyboard out of sync. Note that you can use the same steps to get in in sync again. The bug seems easier to reproduce with an idle cpu. Thanks if you can fix this issue.
Thanks Sebastian. That works for me as a test case too, although maybe somewhat less than 70%. Enough that someone who has an idea how to track this down in the actual code should be able to reproduce. I'm moving this to rawhide now so it doesn't get lost with "ancient" Fedora 13 bugs.
Still here. ★iℊ♥•
I'm not sure what the protocol is, but I seem to have the same bug in Red Hat Enterprise Linux Server Release 6.0. For the record I'll note that there is a similar bug reported in Ubuntu 10.04 and 10.10, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/665956
Thanks. I've cloned this into RHEL6 bug 664484, and also left a brief note on that Ubuntu bug.
I noticed that in Ubuntu 10.04, plugging in a second USB keyboard resets xmodmap back to its default state (removing both the modmap configurations and, apparently, the modmap-related bug). I wonder if that's true in Fedora as well.
problem is caused by autorepeat of the menu key when Mode_Switch is assigned to it. in XKB terms, Mode_Switch is a group switch to the next level that's reverted back to the original when the key is released. with autorepeat, the group starts flipping between 0 and 1 for each repeat event. the last key release then toggles the state back, so depending on when you release it may leave the group at 1 (the key appears stuck). can be reproduced or undone by triggering key repeat on the key but because timing is involved, it's not 100% predictable. not sure of a fix yet.
xorg-x11-server-1.9.3-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.3-4.fc14
(In reply to comment #23) > xorg-x11-server-1.9.3-4.fc14 has been submitted as an update for Fedora 14. > https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.3-4.fc14 I take it you found a fix. Awesome. Is this going into rawhide as well?
rawhide build got submitted yesterday http://koji.fedoraproject.org/koji/buildinfo?buildID=213931
Thanks. But now I get: $ xmodmap -e 'add mod2 = Mode_switch' X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 118 (X_SetModifierMapping) Value in failed request: 0x17 Serial number of failed request: 11 Current serial number in output stream: 11
xorg-x11-server-1.9.3-4.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xorg-x11-server'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.3-4.fc14
try xmodmap -p. If your modmap is the same as mine, Mode_Switch is also assigned to Mod5 and needs to be removed from that first. $ xmodmap -e "add mod2 = Mode_switch" X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 118 (X_SetModifierMapping) Value in failed request: 0x17 Serial number of failed request: 11 Current serial number in output stream: 11 $ xmodmap -e "remove mod5 = Mode_switch" $ xmodmap -e "add mod2 = Mode_switch"
xorg-x11-server-1.9.3-4.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #28) > try xmodmap -p. If your modmap is the same as mine, Mode_Switch is also > assigned to Mod5 and needs to be removed from that first. > > $ xmodmap -e "add mod2 = Mode_switch" > > X Error of failed request: BadValue (integer parameter out of range for > operation) > Major opcode of failed request: 118 (X_SetModifierMapping) > Value in failed request: 0x17 > Serial number of failed request: 11 > Current serial number in output stream: 11 > > $ xmodmap -e "remove mod5 = Mode_switch" > $ xmodmap -e "add mod2 = Mode_switch" Making this change made the xmodmap not give any errors. But now I'm not getting alternate characters in gnome-terminal. Hmmm. Works in Xfce terminal, or right here. ♪♫ So I think that's a separate bug.