Comment 129 for bug 255008

I've marked Bug #512622, filed myself, as duplcate of this bug. It is describing the "wiredness" mentioned in Bug #254939 which I also marked as duplcate. I'm aware it does so in a confusing manner.

Lucid Lynx is also affected.

In the essence my search which also led me here, ends up to following:

Introducing evdev managing keybords resulted in changing keymapping of the non ascii keys (guess!) in a non reasonable way. Did all that keyboards out there change the same? ;o))

At least this is incompatible to xmodmapfiles created for xfree86 driven keyboards.

from my point of view solution could be:

most elegant:
- make evdev output reasonble (i.e xfree86/xmodmap compatible, for all that
  keyboards out there already are ;o)) )

if evdev output is reasonable in any way (I don't believe):
- make xmodmap detect evdev driven keyboard and handle apropriately

or worse:
- kick xmodmap to avoid confusion

grml.org team (recent debian testing) solved that problem by managing the keybord by xfree86 and all the rest by evdev (don't know how, but it works as expected with my "old" xmodmap files)

Worst case in my opinion is to kick xmodmap, because we will loose "xkeycaps" - a great tool to manage complexity of keybord issues in a quit easy and portable manner.

I'm not really an expert, so maybe I'm lost completely with this.

Other conclusions ending in a working solution for this pain always apreciated. :o))