Bug 664484

+++ This bug was initially created as a clone of Bug #537708 +++

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.

--- Additional comment from triage.org on 2009-11-16 10:34:40 EST ---


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

--- Additional comment from mcepl on 2009-11-16 16:32:27 EST ---

(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.

--- Additional comment from mattdm on 2009-12-14 15:59:09 EST ---

Created attachment 378349 [details]
dmesg output

--- Additional comment from mattdm on 2009-12-14 16:00:19 EST ---

Created attachment 378350 [details]
Xorg.0.log

--- Additional comment from mattdm on 2009-12-14 16:06:01 EST ---

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.)

--- Additional comment from mattdm on 2009-12-14 16:06:56 EST ---

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'.

--- Additional comment from campbecg on 2010-01-23 17:18:50 EST ---



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

--- Additional comment from mattdm on 2010-01-23 17:25:17 EST ---

This is still happening, by the way. And I removed the definition for Multi_key, so that's _not_ it.

--- Additional comment from mattdm on 2010-03-13 06:43:17 EST ---

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.

--- Additional comment from mattdm on 2010-03-19 14:36:06 EDT ---

✶°† ™♥i★ i★ ★™ill ♥a☠☠€ñiñℊ wi™♥ ¢urr€ñ™ raw♥i°€• ✓€ry aññ°yiñℊ• Añy ★uℊℊ€★™i°ñ★⁄ Añy ★uℊℊ€★™i°ñ★ a™ all⁄

--- Additional comment from peter.hutterer on 2010-03-21 20:49:56 EDT ---

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?

--- Additional comment from mattdm on 2010-04-30 00:16:00 EDT ---

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.

--- Additional comment from mattdm on 2010-04-30 00:18:42 EDT ---

Created attachment 410301 [details]
xkbcomp -xkb $DISPLAY -

--- Additional comment from mattdm on 2010-06-03 21:02:30 EDT ---

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.

--- Additional comment from bug on 2010-07-08 09:05:54 EDT ---

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).

--- Additional comment from redhat.20.sepp on 2010-10-10 15:49:27 EDT ---

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.

--- Additional comment from mattdm on 2010-10-19 09:42:22 EDT ---

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.

--- Additional comment from mattdm on 2010-12-07 15:59:53 EST ---

Still here. ★iℊ♥•

--- Additional comment from holtzermann17 on 2010-12-20 09:45:58 EST ---

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