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
Attachment:
signature.asc
Description: PGP signature