Bug 537708 - xmodmap Mode_switch gets stuck on
Summary: xmodmap Mode_switch gets stuck on
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 664484
TreeView+ depends on / blocked
 
Reported: 2009-11-15 22:03 UTC by Matthew Miller
Modified: 2018-04-11 08:08 UTC (History)
6 users (show)

Fixed In Version: xorg-x11-server-1.9.3-4.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 664484 (view as bug list)
Environment:
Last Closed: 2011-01-19 21:10:43 UTC
Type: ---


Attachments (Terms of Use)
dmesg output (55.25 KB, text/plain)
2009-12-14 20:59 UTC, Matthew Miller
no flags Details
Xorg.0.log (61.35 KB, text/plain)
2009-12-14 21:00 UTC, Matthew Miller
no flags Details
xmodmap (1.29 KB, text/plain)
2009-12-14 21:06 UTC, Matthew Miller
no flags Details
xkbcomp -xkb $DISPLAY - (56.64 KB, text/plain)
2010-04-30 04:18 UTC, Matthew Miller
no flags Details
xmodmap to reproduce probla (11.52 KB, text/plain)
2010-10-10 19:49 UTC, Sebastian Biallas
no flags Details

Description Matthew Miller 2009-11-15 22:03:07 UTC
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.

Comment 1 Bug Zapper 2009-11-16 15:34:40 UTC
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

Comment 2 Matěj Cepl 2009-11-16 21:32:27 UTC
(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.

Comment 3 Matthew Miller 2009-12-14 20:59:09 UTC
Created attachment 378349 [details]
dmesg output

Comment 4 Matthew Miller 2009-12-14 21:00:19 UTC
Created attachment 378350 [details]
Xorg.0.log

Comment 5 Matthew Miller 2009-12-14 21:06:01 UTC
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.)

Comment 6 Matthew Miller 2009-12-14 21:06:56 UTC
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'.

Comment 7 Chris Campbell 2010-01-23 22:18:50 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Matthew Miller 2010-01-23 22:25:17 UTC
This is still happening, by the way. And I removed the definition for Multi_key, so that's _not_ it.

Comment 9 Matthew Miller 2010-03-13 11:43:17 UTC
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.

Comment 10 Matthew Miller 2010-03-19 18:36:06 UTC
✶°† ™♥i★ i★ ★™ill ♥a☠☠€ñiñℊ wi™♥ ¢urr€ñ™ raw♥i°€• ✓€ry aññ°yiñℊ• Añy ★uℊℊ€★™i°ñ★⁄ Añy ★uℊℊ€★™i°ñ★ a™ all⁄

Comment 11 Peter Hutterer 2010-03-22 00:49:56 UTC
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?

Comment 12 Matthew Miller 2010-04-30 04:16:00 UTC
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.

Comment 13 Matthew Miller 2010-04-30 04:18:42 UTC
Created attachment 410301 [details]
xkbcomp -xkb $DISPLAY -

Comment 14 Matthew Miller 2010-06-04 01:02:30 UTC
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.

Comment 15 Pavel Polyakov 2010-07-08 13:05:54 UTC
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).

Comment 16 Sebastian Biallas 2010-10-10 19:49:27 UTC
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.

Comment 17 Matthew Miller 2010-10-19 13:42:22 UTC
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.

Comment 18 Matthew Miller 2010-12-07 20:59:53 UTC
Still here. ★iℊ♥•

Comment 19 Joe Corneli 2010-12-20 14:45:58 UTC
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

Comment 20 Matthew Miller 2010-12-20 15:11:44 UTC
Thanks. I've cloned this into RHEL6 bug 664484, and also left a brief note on that Ubuntu bug.

Comment 21 Joe Corneli 2011-01-07 11:26:52 UTC
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.

Comment 22 Peter Hutterer 2011-01-12 22:02:11 UTC
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.

Comment 23 Fedora Update System 2011-01-14 00:54:57 UTC
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

Comment 24 Matthew Miller 2011-01-14 01:30:12 UTC
(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?

Comment 25 Peter Hutterer 2011-01-14 01:46:18 UTC
rawhide build got submitted yesterday

http://koji.fedoraproject.org/koji/buildinfo?buildID=213931

Comment 26 Matthew Miller 2011-01-14 03:49:44 UTC
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

Comment 27 Fedora Update System 2011-01-14 20:32:03 UTC
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

Comment 28 Peter Hutterer 2011-01-18 04:32:33 UTC
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"

Comment 29 Fedora Update System 2011-01-19 21:10:37 UTC
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.

Comment 30 Matthew Miller 2011-01-19 22:46:41 UTC
(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.


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