This bug seems to be the same one as reported in the Debian Bugtracker under http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514053.

Investigation there showed that running xmodmap _before_ the first key press has occured does not work as desired, but it works afterwards. This is why it works when xmodmap is called from a terminal. Also, people who do not use any kind of auto-login (e.g. GDM’s auto-login) are not affected by this bug. I hope this informations enables you to track down and fix this bug.

I’d say #13052 is a duplicate of this bug if it weren’t so old – I’m sure that it was working for me at that time and broke not that long ago.

Indeed, pressing a key before xmodmap is invoked "fixes" this bug (I placed the xmodmap call in my window manager's startup script, prefixed with a "sleep 5 &&"). So it must be some kind of missing initialization that isn't performed until the first key-press, and invoking xmodmap before that "breaks" the AltGR key.

In any case, this is some kind of regression, because I was using the same setup without problems on the 7.3 version, and this problem only presented itself when I updated to 7.4...

Hi. I’m getting tired of manually running "setxkbmap ; xmodmap ~/.Xmodmap" after each system start :-). Is there anything I can help here? Do you already have an idea in what components the bug might be hidden?

Some more information: When running xmodmap -pke directly after X starts, before any keypress or calls to xmodmap, the keyboard map seems to be the default, i.e. US keyboard. This means that the hal settings, e.g. input.xkb.layout = 'de'  (string), are not applied until the first key press happens.

A blind guess might be that xf86NewInputDevice in ./hw/xfree86/common/xf86Xinput.c does not call EnableDevice at X startup, maybe because we have not switched to the vt yet, and the hal settings are applied in EnableDevice (and not in ActivateDevice).

This might be related to #16364 and #12523. The fix 9c5dd7337fa93fb1650cc017e523b939dcbf482a mentioned in #16364 is included in 1.6.5, is it? Because then it does not properly fix the issue.

(In reply to comment #3)
> Hi. I’m getting tired of manually running "setxkbmap ; xmodmap ~/.Xmodmap"
> after each system start :-). Is there anything I can help here? Do you already
> have an idea in what components the bug might be hidden?
> 

Hi,

my current Hack is to rename .Xmodmap to .my-Xmodmap and in XFCE's autostart I've added the following command: zenity --info --text="Press any key to load xmodmap" && xmodmap ~/.my-Xmodmap
So all I have to do is to press the return key after (auto-)logging in and contrary to a call of setxkbmap it does not take several seconds until you can use the system again :-)


HTH,

Geralt.

(In reply to comment #5)
> This might be related to #16364 and #12523. The fix
> 9c5dd7337fa93fb1650cc017e523b939dcbf482a mentioned in #16364 is included in
> 1.6.5, is it? Because then it does not properly fix the issue.

This fix was merged before 1.6.0 so it's included in any 1.6.x release.
Can you reproduce the issue in server 1.7?

(In reply to comment #7)
> (In reply to comment #5)
> > This might be related to #16364 and #12523. The fix
> > 9c5dd7337fa93fb1650cc017e523b939dcbf482a mentioned in #16364 is included in
> > 1.6.5, is it? Because then it does not properly fix the issue.
> 
> This fix was merged before 1.6.0 so it's included in any 1.6.x release.
> Can you reproduce the issue in server 1.7?

Yes, same behaviour, although there is now an additional odditiy with xmodmap, not sure if it’s related:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564327

Greetings,
Joachim

I just recalled that you have to remove the modifiers first.
Please try this in your .xmodmap:

        clear Mod4
        keycode 135 = Super_R
        add Mod4 = Super_R

If 'clear' doesn't work please try to 'remove' selectively for all
entries of `xmodmap -pm | grep mod4` like:
        remove Mod4 = Super_R
        remove Mod4 = Hyper_R
        keycode 135 = Super_R
        add Mod4 = Super_R
        add Mod4 = Hyper_R

Report update.

Recently Xorg 7.4 went stable on my distro (Gentoo), and upon updating, I noticed that this bug no longer manifests itself. So unless someone else still has this problem, I would consider this issue somehow fixed in 7.4

(In reply to comment #10)
> Report update.
> 
I forgot to attach the related version updates :/

xmodmap 1.0.4
xf86-input-keyboard 1.4.0
Xorg 7.4

I'm running

Xorg 7.4
xorg-server 1.7.6
xf86-input-evdev 2.3.2

on Gentoo and although I no longer get those corrupted keys autoloading the following .Xmodmap on startup is without any effect:

! Rebind the capslock-key to ctrl
remove Lock = Caps_Lock
keysym Caps_Lock = Control_L
add Control = Control_L


and when I try to reload it via xmodmap ~/.Xmodmap I get the following error:
xmodmap:  /home/sascha/.Xmodmap.ctrl:2:  bad keysym in remove modifier list 'Caps_Lock', no corresponding keycodes
xmodmap:  /home/sascha/.Xmodmap.ctrl:3:  bad keysym target keysym 'Caps_Lock', no corresponding keycodes
xmodmap:  2 errors encountered, aborting.


I'm not sure if this bug is the same as bug 24551



Geralt

(In reply to comment #12)
> I'm running
> 
> Xorg 7.4
> xorg-server 1.7.6
> xf86-input-evdev 2.3.2
> 
> on Gentoo and although I no longer get those corrupted keys autoloading the
> following .Xmodmap on startup is without any effect:
> 
> ! Rebind the capslock-key to ctrl
> remove Lock = Caps_Lock
> keysym Caps_Lock = Control_L
> add Control = Control_L
> 
> 
> and when I try to reload it via xmodmap ~/.Xmodmap I get the following error:
> xmodmap:  /home/sascha/.Xmodmap.ctrl:2:  bad keysym in remove modifier list
> 'Caps_Lock', no corresponding keycodes
> xmodmap:  /home/sascha/.Xmodmap.ctrl:3:  bad keysym target keysym 'Caps_Lock',
> no corresponding keycodes
> xmodmap:  2 errors encountered, aborting.
> 
> 
> I'm not sure if this bug is the same as bug 24551
> 
> 
> 
> Geralt

the one in 24551 is a typo, I'm talking about bug 24552 (*this* bug)

On Wed, May 05, 2010 at 01:32:16AM -0700, bugzilla-daemon@freedesktop.org wrote:
> I'm running
> 
> Xorg 7.4
> xorg-server 1.7.6
> xf86-input-evdev 2.3.2
> 
> on Gentoo and although I no longer get those corrupted keys autoloading the
> following .Xmodmap on startup is without any effect:
> 
> ! Rebind the capslock-key to ctrl
> remove Lock = Caps_Lock
> keysym Caps_Lock = Control_L
> add Control = Control_L
> 
> 
> and when I try to reload it via xmodmap ~/.Xmodmap I get the following error:
> xmodmap:  /home/sascha/.Xmodmap.ctrl:2:  bad keysym in remove modifier list
> 'Caps_Lock', no corresponding keycodes
> xmodmap:  /home/sascha/.Xmodmap.ctrl:3:  bad keysym target keysym 'Caps_Lock',
> no corresponding keycodes
> xmodmap:  2 errors encountered, aborting.
> 
> I'm not sure if this bug is the same as bug 24551

Sounds like your XKeySymDB is broken? Can you attach the output of:
strace -e file xmodmap ~/.Xmodmap

(In reply to comment #14)
> On Wed, May 05, 2010 at 01:32:16AM -0700, bugzilla-daemon@freedesktop.org
> wrote:
> > I'm running
> > 
> > Xorg 7.4
> > xorg-server 1.7.6
> > xf86-input-evdev 2.3.2
> > 
> > on Gentoo and although I no longer get those corrupted keys autoloading the
> > following .Xmodmap on startup is without any effect:
> > 
> > ! Rebind the capslock-key to ctrl
> > remove Lock = Caps_Lock
> > keysym Caps_Lock = Control_L
> > add Control = Control_L
> > 
> > 
> > and when I try to reload it via xmodmap ~/.Xmodmap I get the following error:
> > xmodmap:  /home/sascha/.Xmodmap.ctrl:2:  bad keysym in remove modifier list
> > 'Caps_Lock', no corresponding keycodes
> > xmodmap:  /home/sascha/.Xmodmap.ctrl:3:  bad keysym target keysym 'Caps_Lock',
> > no corresponding keycodes
> > xmodmap:  2 errors encountered, aborting.
> > 
> > I'm not sure if this bug is the same as bug 24551
> 
> Sounds like your XKeySymDB is broken? Can you attach the output of:
> strace -e file xmodmap ~/.Xmodmap

The output is
$ strace -e file xmodmap ~/.Xmodmap
execve("/usr/bin/xmodmap", ["xmodmap", "/home/sascha/.Xmodmap"], [/* 60 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/usr/lib/libX11.so.6", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/usr/lib/libxcb.so.1", O_RDONLY)  = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/usr/lib/libXau.so.6", O_RDONLY)  = 3
open("/usr/lib/libXdmcp.so.6", O_RDONLY) = 3
access("/home/sascha/.Xauthority", R_OK) = 0
open("/home/sascha/.Xauthority", O_RDONLY) = 4
open("/home/sascha/.Xmodmap", O_RDONLY) = 4
open("/usr/share/X11/XKeysymDB", O_RDONLY) = 5
open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 5
open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 5
access("/usr/share/X11/locale/C/XLC_LOCALE", R_OK) = 0
open("/usr/share/X11/locale/C/XLC_LOCALE", O_RDONLY) = 5
open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 5
open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 5
access("/usr/share/X11/locale/C/XLC_LOCALE", R_OK) = 0
open("/usr/share/X11/locale/C/XLC_LOCALE", O_RDONLY) = 5
xmodmap:  /home/sascha/.Xmodmap:10:  bad keysym in remove modifier list 'Caps_Lock', no corresponding keycodes
xmodmap:  /home/sascha/.Xmodmap:11:  bad keysym target keysym 'Caps_Lock', no corresponding keycodes
xmodmap:  2 errors encountered, aborting.




Geralt

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.