[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#409612: marked as done (xlibs-data: Modifier mappings broken)

Your message dated Fri, 28 Jan 2011 03:45:56 +0100
with message-id <20110128024556.GG27488@debian.org>
and subject line Closing #409612
has caused the Debian Bug report #409612,
regarding xlibs-data: Modifier mappings broken
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

409612: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409612
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: xlibs-data
Version: 1:7.1.0-11
Severity: important

The modifier mappings in stock keyboard layouts are broken.
For details, I'll just attach the Ion FAQ entry below from
(I have not myself experienced that problem, though -- I don't
use Xkb crud at all, because customisation of Xkb based layouts
is too laboursome, difficult, undocumented etc. -- but users have 
experienced it on various systems, and this seems the easiest 
channel to report the problem.)


_Ion doesn't notice that a modifier has been released
(in actions that use like `kpress_wait`, such as META+C, 
or in “grabmenus”)._

This is most likely to be an X bug/keyboard misconfiguration,
when you have changed the “META” key of Ion to Mod4, or 
something else that supposed has one of the Win-keys bound to
it. For some reason, some Xorg comes with some totally broken
stock keyboard layouts that define multiple keycodes for the 
`Super_L` and such “keysyms”, one of them spurious. However, 
various part of X or Xlib can not handle that, and report the
wrong keycode when queried.<sup>1</sup>

To check if this is the case, first run `xmodmap` to check
what key is bound to the Mod4 (or perhaps Mod3 depending
on the configuration) modifier. You may see a line like

    mod4        Super_L (0x7f),  Hyper_L (0x80)

The number 0x7f=127 is the keycode, and this is highly likely 
the wrong keycode. Check with `xmodmap -pke|grep Super_L`
to see what keycodes have `Super_L` bound to them. If you
see something like this, your keymap is misconfigured:

    keycode 115 = Super_L
    keycode 127 = NoSymbol Super_L

The keycode 115 is the keycode for the real left Win key,
and 127 is spurious. However, the modifier subsystem only
seems to see the latter. Putting the following commands
in `~/.Xmodmap` and runnning `xmodmap ~/.Xmodmap` should
fix the issue. You may also want/need to repeat for the 
other Win keys (`Hyper_L` and 0x80=127 in our example case).

    remove mod4 = Super_L
    keycode 127 = NoSymbol
    add mod4 = Super_L

(The `remove` command is needed for some reason to not confuse X.)
Unless your system configuration is totally weird (and I wouldn't 
put it past systems built to run Gnome), next time you start X, 
`~/.Xmodmap` should be loaded automatically. On a working modifier
configuration running `xmodmap` should display a line like below
(0x73 following `Super_L` being the important part).

    mod4        Super_L (0x73)


<sup>1</sup> `XKeysymToKeycode` in particular can only
return one keycode. However, `XGetModifierMapping` should
be able to report more, but for some reason doesn't. 
Maybe it uses the former.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)

Versions of packages xlibs-data depends on:
ii  libx11-6                      2:1.0.0-8  X11 client-side library
ii  xbitmaps                      1.0.1-2    Base X bitmaps
ii  xcursor-themes                1.0.1-4    Base X cursor themes

xlibs-data recommends no packages.

-- no debconf information

--- End Message ---
--- Begin Message ---
Submitter doesn't want to upgrade from etch, can't do much, closing.


Attachment: signature.asc
Description: Digital signature

--- End Message ---

Reply to: