Recently the keyboard layout within X has started unexpectedly
reconfiguring itself.  The problem may somehow be related to
suspend-to-RAM events, but that's just a guess.  The machine in question
is a thinkpad x300.

Not all keys are affected.  The affected keys seem to be the arrow keys,
the right Control and Alt keys, and the Insert, Delete, Page Up, etc.
cluster.  xev shows, for example, that Page Down gets mapped to Menu,
while Page Up gets mapped to KP_Divide.

Switching keyboard layout and options using KDE's xkb interface doesn't
seem to have any effect, nor does changing to a VT and back to X.

noah

Le jeudi 27 août 2009 13:31:22 Noah Meyerhans, vous avez écrit :

Hi Noah, hi xserver-xorg-input-evdev maintainers,

I am experiencing exactly the same behaviour. I can recover big parts of my
keyboard layout by using setxkbmap, but the arrows never get back to something
useable (having PrintScreen triggered instead of "up" is _really_ annoying)
without an X restart.

I am hesitant about the severity (I'd have set it "serious"), but it's not my
call…

Best regards,

OdyX

Sounds like something is resetting the xkb rules to base instead of
evdev.  Most likely not a driver bug.  You're both kde users?

Cheers,
Julien

Le jeudi 27 août 2009 14:21:52 Julien Cristau, vous avez écrit :

Hi Julien,

I am using KDE and from what I read in Noah's mail, he also is…

Assuming that it is a KDE bug, what should we grep/strace for ?

Regards,

OdyX

Hi all,

I want to give a temporarily quick fix to this problem.

I don't know exactly what's wrong with the default input hotplugging
keyboard detection, but after asking help on #debian irc. The problem
probably is related to evdev driver. Disable input hotplugging and use
"kbd" driver fix the problem, as described below:

1. disable X input hotplugging:
add the following to your /etc/X11/xorg.conf:

Section "ServerFlags"
    Option "AutoAddDevices" "False"
    Option "AllowEmptyInput" "False"
EndSection

This will tell X to use the input config in xorg.conf.

2. make sure your keyboard config is correct, for us keyboard, it
should be something like:

Section "InputDevice"
	Identifier	"Generic Keyboard"
	Driver		"kbd"
	Option		"XkbRules"	"xorg"
	Option		"XkbModel"	"pc104"
	Option		"XkbLayout"	"us"
EndSection

3. restart X.

By the way, I'm using GNOME env, so it's not specific to KDE. And I
also see someone using RHEL has the same problem. This could be a
general X issue instead of distro issue.

Hope that helps,
Yuanle

I guess you could attach a debugger to the server and put a breakpoint
where mapping change events are generated, to figure out what triggers
them.

Cheers,
Julien

It's not a fix.

Cheers,
Julien

Workaround worked for me

USB keyboard here, Microsoft Natural Ergonomic 4000. Same symptoms,
left and up arrows + the Del/Ins group got mapped to other stuff.
Plus, mouse buttons (including scroll wheel turns) emited extra stuff
with negative impact in some shooter games such as OpenArena and
Tremulous (any click made the character face straight down). The mouse
is also an USB mouse (Ideazon Reaper Edge). Also tried another mouse
(office Logitech USB mouse) and a no-name PS/2 keyboard.

FWIW, everything was affected the same way, so it looks like it's not
a matter of just-USB or just-keyboard/mouse, or just a specific
peripheral. Seems like a more global problem.

It's not a fix in the long run and we need to discover what's actually
wrong, but as a workaround Yuanle's solution is good.

Hi,
I had similar problems with the keyboard on FJS Amilo laptop. Down arrow generated Key_Down and Return events, some other arrow keys generated also partially wrong events. Page Up added to PageUp also "/", Del generated PrintScreent event, etc.

Additionally, the keyboard driver randomly repeated pressed keys even when pressed for very short time (really randomly, but in average let say every 20-30th key). I don't know why it happens, maybe it's related to processor load so the driver thinks that the key is pressed for longer time than it really is, but that's just idea... Moreover, sometimes the repeated key was sent after another key was pressed, i.e. typing "word" resulted into "wordr" etc.

I have XkbdModel set to "fscaa1667g", but also tried "pc102" and some others and it had no influence to the mentioned behavior.

Also, it was not related to window manager settings, I tried KDE, twm and simple xterm as window manager and all of them had the same problem.

The kernel keyboard had no such problems, typing in console was correct. I didn't try to check /dev/input/eventX, if you want to do some test, please let me know.

The work-around was to disable SendCoreEvents in keyboard section:
        Option          "SendCoreEvents"        "false"

After that the keyboard works correctly, no typos or repeats, no strange mappings etc.

Xorg log now reports the following messages on keyboard:
(==) |-->Input Device "Generic Keyboard"
(==) The core pointer device wasn't specified explicitly in the layout.
        Using the first mouse device.
(==) The core keyboard device wasn't specified explicitly in the layout.
        Using the first keyboard device.
...
(**) Option "SendCoreEvents" "false"
(**) Generic Keyboard: doesn't report core events
(**) Option "Protocol" "standard"
(**) Generic Keyboard: Protocol: standard
(**) Option "XkbRules" "xorg"
(**) Generic Keyboard: XkbRules: "xorg"
(**) Option "XkbModel" "fscaa1667g"
(**) Generic Keyboard: XkbModel: "fscaa1667g"
(**) Option "XkbLayout" "us"
(**) Generic Keyboard: XkbLayout: "us"
(**) Option "CustomKeycodes" "off"
(**) Generic Keyboard: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD)
...
(**) "Power Button": always reports core events
(**) "Power Button": Device: "/dev/input/event2"
(II) "Power Button": Found keys
(II) "Power Button": Configuring as keyboard
(II) XINPUT: Adding extended input device ""Power Button"" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc102"
(**) Option "xkb_layout" "us"
(**) Option "xkb_options" "lv3:ralt_switch,terminate:ctrl_alt_bksp"
...
(II) XINPUT: Adding extended input device ""Sleep Button"" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc102"
(**) Option "xkb_layout" "us"
(**) Option "xkb_options" "lv3:ralt_switch,terminate:ctrl_alt_bksp"
(II) config/udev: Adding input device "AT Translated Set 2 keyboard" (/dev/input/event0)
(**) "AT Translated Set 2 keyboard": always reports core events
(**) "AT Translated Set 2 keyboard": Device: "/dev/input/event0"
(II) "AT Translated Set 2 keyboard": Found keys
(II) "AT Translated Set 2 keyboard": Configuring as keyboard
(II) XINPUT: Adding extended input device ""AT Translated Set 2 keyboard"" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc102"
(**) Option "xkb_layout" "us"
(**) Option "xkb_options" "lv3:ralt_switch,terminate:ctrl_alt_bksp"
...
(II) config/udev: Adding input device "ACPI Virtual Keyboard Device" (/dev/input/event8)
(**) "ACPI Virtual Keyboard Device": always reports core events
(**) "ACPI Virtual Keyboard Device": Device: "/dev/input/event8"
(II) "ACPI Virtual Keyboard Device": Found keys
(II) "ACPI Virtual Keyboard Device": Configuring as keyboard
(II) XINPUT: Adding extended input device ""ACPI Virtual Keyboard Device"" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc102"
(**) Option "xkb_layout" "us"
(**) Option "xkb_options" "lv3:ralt_switch,terminate:ctrl_alt_bksp"

Best Regards,
         Zbynek

Sounds like a configuration error.  Did you disable AllowEmptyInput?  If
so, all bets are off, this is not supported, and won't work.  Don't do
that.

Cheers,
Julien

Yes, you're right, I disabled it two months ago because HAL reported completely wrong information about keyboard.
With AllowEmptyInput set to default value it works, no matter what's in keyboard section.

Thanks,
        Zbynek

Hello,

I also ran into this bug, not on KDE, but Gnome, they're both
affected ion the same way. Before findinmg this bug description, I
tried many things without any success.

Disabling Evdev works here, I've not yet tried unsetting
"AllowEmptyInput", which was set to "0" here in the "ServerLayout"
section, and re-enabling Evdev afterwards.

If this Option is unsupported, why is it there in the first place?
Until recently, it did not do any harm. I guess I've copied it from a
configuration example along with another line, a thing many users will
do, so it is likely that many people will run into this issue when
upgrading to Squeeze once it becomes stable. Lenny is seems not to be
affected.

I'd like to help resolving the bug, so I provide information how the
bug affected me here and my findings with "xkeycaps" on a german
keyboard:

Eventually I got the seemingly random remappimg here, and a reboot
normally helped resolving this, so I thought a hardware confusion
because of my old mechanical KVM switch to be the reason, until I
upgraded most packages to Squeeze. From this point in time on the
remapping issue became permanent.

Because the text consoles VT 1...6 were never affected, this could not
be a hardware issue. I even changed the keyboard before being sure
about that, which of course did not help.

I then found that this is not a simple false mapping. All affected
keyboard keys are bound to *two* keycodes which are sent immediately
after one another, the false one before the correct one. You can see
that in Xkeycaps. Remapping with Xmodmap won't help, because you can
only remap the 2nd keycode, not the erronneous first one. The "Arrow
Up" key will call the "Print Screen" window in Gnome, which then
receives the "Up Arrow" keyboard event, for example.

Short explanation of german keyboard remapping description, which I
paste below, pleas asl when unsure:
NB_ = KP_
Pfeil_ = Arrow keys with direction < ^ V >
Bild_ = Page up/down

"Remapping":
=8<============================
Pos1		Pause
Bild_^		NB_/
NB_/		Einfg
NB_Enter	Pfeil_V
Ende		Win_L
Bild_V		Menü
AltGr		NB_Enter
Strg_R		Bild_V
Pfeil_<		AltGr
Pfeil_^		Druck
Pfeil_V		Menü
=8<============================

Depending on the chosen configuration (probably changing between
"evdev", "ACPI" or "PC-105" keyboard types or between layouts, I'm not
sure what changes this), the Right Alt key ("Alt Gr") is mapped either
to "KP_ENTER" or to the Left Arrow key.

So the keys on the right side (the additionally triggered keycodes)
might vary, but I'm quite sure that the list of the keys actually
pressed on the left side is complete. I found never any other key to be
affected.

The really weird thing is that the effect was seemingly random at
first, and became a permanent change later. So I cannot tell you
exactly which particular package upgrades have caused this.

It is, however, a system wide effect in X, and not depending from
the desktop environment used.

I'd really like to see this bug resolved, because I spent lots of hours
debugging and searching on the Internet before finding this bug report.
I doubt that "normal users" (especially those not speaking much
english) would ever succeed resolving that issue when running into it
because it just works with a fresh installation with the modern
approach of having X configuring itsself automatically, so all people I
asked about it have never heard of this issue.

Please keep in mind that removing "xorg.conf" is not an option for
people with older hardware. I, for example, need the proprietary Nvidia
driver, or any programme using OpenGL would turn into a slide show. My
serial mouse on my mechanical KVM switch does not work at all unless
configured by hand in "xorg.conf". You typically do that by looking for
configuration examples on the web and copying from them until it works
without reading and understanding the X source code first. It's very
annoying that perfectly valid configurations lead to an unusable system
even years later due to an unavoidable software upgrade.

Don't get my words wrong - I really appreciate your good work, but I
consider this to be a release critical bug for Squeeze because it can
make desktop systems unusable. If it cannot be resolved, the package
should at least detect the offending configuration option(s) in the
active "xorg.conf" and issue a warning about that to the user with
instructions how to change the setting(s) (preferrably in their
language, not just in english).

Best regards, Christoph

As it happens, http://patchwork.freedesktop.org/patch/2581/ was posted
earlier today.

Cheers,
Julien