Bug 24094

No insight to be gained from Xorg.0.log either?

On Tue, Sep 22, 2009 at 03:39:15PM -0700, bugzilla-daemon@freedesktop.org wrote:
> No insight to be gained from Xorg.0.log either?

It's definitely got the right keymap, but actions aren't being run.

Created attachment 29781 [details]
My Xorg.0.log file

Reply to comment #1 From Alan Coopersmith 2009-09-22 15:39:15 PST:
> No insight to be gained from Xorg.0.log either?

Here's your chance to find out.

-Carl

Yeah, doesn't seem to be helpful.  VT's look like they initialized okay:
(++) using VT number 7
and no errors from trying to switch and failing.

Lots of "(EE) Trying to set already set cursor." errors though.

> --- Comment #4 from Alan Coopersmith <alan.coopersmith@sun.com>  2009-09-22 17:21:17 PST ---
> Lots of "(EE) Trying to set already set cursor." errors though.

unrelated and already fixed in master.
http://lists.freedesktop.org/archives/xorg-devel/2009-September/002130.html

Any update on this? Is this still an issue? (I don't have the slightest clue what could be going on)

No update, moving to 1.7.1.

(In reply to comment #6)
> Any update on this? Is this still an issue? (I don't have the slightest clue
> what could be going on)

I don't have any update other than that it is still an issue for me.

(In reply to comment #7)
> No update, moving to 1.7.1.

I'll leave the release planning to you, (Daniel originally suggested I make this
a blocking bug).

I have a suspicion that I must have done something odd, (such as forgottting
to update some module, or accidentally mixing something somewhere between my
distribution's X stuff and my custom-prefix X stuff)---if only because I'm
not aware of other people having this problem generally.

I'm still happy for any suggestions of things I might try. (Peter, too bad you
couldn't be here for XDC---it would have been fun to see you then---and fun
to just hand you my laptop with non-working VT switch.) :-)

-Carl

(In reply to comment #8)
> I have a suspicion that I must have done something odd, (such as forgottting
> to update some module, or accidentally mixing something somewhere between my
> distribution's X stuff and my custom-prefix X stuff)---if only because I'm
> not aware of other people having this problem generally.

that's the thing though. IIRC xkbcomp should give you an error if you're using the old one against the new server and the other way round. Either way, if the keymap (the output from xkbcomp) looks sane it suggests it's not a broken keymap.

right now I think it is some weird combinations of versions + possibly custom settings (do you have an .xmodmaprc?) but I can't figure out how to reproduce it.

out of interest - does zapping work?
if you hit Shift+Numlock and use the keypad's 2,4,6,8 keys, does the pointer move around?

> I'm still happy for any suggestions of things I might try. (Peter, too bad you
> couldn't be here for XDC---it would have been fun to see you then---and fun
> to just hand you my laptop with non-working VT switch.) :-)

tbh, I'd have loved to do that, just to figure out where things to wrong.

Oh, even though daniel said they look normal, please attach the keymap file (xkbcomp -xkb :0 -)

(In reply to comment #9)
> right now I think it is some weird combinations of versions + possibly custom
> settings (do you have an .xmodmaprc?)

I don't *think* I'm currently loading any .xmodmap files, (the only one I have in my home directory is ~/.Xmodmap-disabled but I can't be certain that GNOME hasn't decided to start loading that).
 
> out of interest - does zapping work?

No. But interestingly, I recently noticed that zapping and VT switching *do* work from the GDM login screen, (just not after I've logged in).

> if you hit Shift+Numlock and use the keypad's 2,4,6,8 keys, does the pointer
> move around?

Yes, that actually does work. (I'd never seen that feature before.)

> Oh, even though daniel said they look normal, please attach the keymap file
> (xkbcomp -xkb :0 -)

Will do.

-Carl

Created attachment 30973 [details]
Output of "xkbcomp -xkb :0 -"

Let me know what you see.

-Carl

(In reply to comment #10)
> > out of interest - does zapping work?
> 
> No. But interestingly, I recently noticed that zapping and VT switching *do*
> work from the GDM login screen, (just not after I've logged in).

can you reset your keyboard config to the default then? Or try with a test user that doesn't have keyboard configuration. Might be that one of your many options is messing it up somehow?


> > if you hit Shift+Numlock and use the keypad's 2,4,6,8 keys, does the pointer
> > move around?
> 
> Yes, that actually does work. (I'd never seen that feature before.)

That indicates that at least actions are working then. My first guess would be
altwin(alt_super_win), since the actions you're trying to do include the alt key and that's the only option that modifies it.

(In reply to comment #12)
> (In reply to comment #10)
> > > out of interest - does zapping work?
> > 
> > No. But interestingly, I recently noticed that zapping and VT switching *do*
> > work from the GDM login screen, (just not after I've logged in).
> 
> can you reset your keyboard config to the default then? Or try with a test user
> that doesn't have keyboard configuration. Might be that one of your many
> options is messing it up somehow?

I did verify that with a test user things work just fine.

I also switched from using GNOME to using xfce4 and things are also working fine
for me.

So it's definitely a problem that's specific to my configuration.

I've got no fear of scrambling my GNOME configuration now that I'm not using it,
so I'll be glad to try to isolate this. I'll let you know if I learn anything.

-Carl

(In reply to comment #12)
> That indicates that at least actions are working then. My first guess would be
> altwin(alt_super_win), since the actions you're trying to do include the alt
> key and that's the only option that modifies it.

Yes, that's it.

If I run gnome-keyboard-properties and set "Alt/Win key behavior" to "default"
then CTRL-ALT-F1 works just fine. In this case, xmodmap shows:

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock      
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Multi_key (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

If I then set "Alt/Win key behavior" to "Alt is mapped to Right Win, Super
to Menu" then I get the buggy CTRL-ALT-F1 (with either left or right alt
key). And in this case, xmodmap shows:

xmodmap:  up to 5 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock      
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Multi_key (0x85),  Alt_R (0x86),  Super_R (0x87),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

-Carl

PS. How can I switch these XKB settings without gnome-keyboard-properties?
I thought I might be able to use setxkbmap, but I couldn't find documentation
on available options. I even tried digging into /usr/share/X11/rules/base
and then tried running commands like:

    setxkbmap -option altwin:alt_super_win

But that didn't seem to take effect.

(In reply to comment #12)
> If I then set "Alt/Win key behavior" to "Alt is mapped to Right Win, Super
> to Menu" then I get the buggy CTRL-ALT-F1 (with either left or right alt
> key).

verified.

> PS. How can I switch these XKB settings without gnome-keyboard-properties?
> I thought I might be able to use setxkbmap, but I couldn't find documentation
> on available options. I even tried digging into /usr/share/X11/rules/base
> and then tried running commands like:
> 
>     setxkbmap -option altwin:alt_super_win
> 
> But that didn't seem to take effect.

make sure you use enough quotes and reset the options before adding new
ones. by default "option" adds to the existing one so usually the command
neede is 

setxkbmap -option "" -option "altwin:alt_super_win"

if I run this command here, I can see the gibberish instead of the VT
switch.

there's no documentation of options that I know of, setxkbmap doesn't have a
way of printing them and the only way to 'easily' get them is to read
/usr/share/X11/rules/evdev (base is for the kbd driver, mostly the same
in regards to options though).

(In reply to comment #15)
> (In reply to comment #12)
> > If I then set "Alt/Win key behavior" to "Alt is mapped to Right Win, Super
> > to Menu" then I get the buggy CTRL-ALT-F1 (with either left or right alt
> > key).
> 
> verified.

Great. I'm glad the bug is firmly in your hands now. :-)

> >     setxkbmap -option altwin:alt_super_win
> > 
> > But that didn't seem to take effect.
> 
> make sure you use enough quotes and reset the options before adding new
> ones. by default "option" adds to the existing one so usually the command
> neede is 
> 
> setxkbmap -option "" -option "altwin:alt_super_win"

Ah, OK. That makes sense. (I also wondered why I didn't see any equivalent of
"default" in the rules file.)

> there's no documentation of options that I know of, setxkbmap doesn't have a
> way of printing them and the only way to 'easily' get them is to read
> /usr/share/X11/rules/evdev (base is for the kbd driver, mostly the same
> in regards to options though).

OK. Thanks for clarifying things for me.

-Carl

nasty, nasty, nasty. looking at the output of xkbcomp before and after
applying the option, the difference that's interesting is:

    interpret XF86_Ungrab+AnyOfOrNone(all) {
        repeat= True;
        action= Private(type=0x86,data[0]=0x55,data[1]=0x6e,data[2]=0x67,data[3]=0x72,data[4]=0x61,data[5]=0x62,data[6]=0x00);
    };
    interpret XF86_ClearGrab+AnyOfOrNone(all) {
        repeat= True;
        action= Private(type=0x86,data[0]=0x43,data[1]=0x6c,data[2]=0x73,data[3]=0x47,data[4]=0x72,data[5]=0x62,data[6]=0x00);
    };
    interpret XF86_Next_VMode+AnyOfOrNone(all) {
        repeat= True;
        action= Private(type=0x86,data[0]=0x2b,data[1]=0x56,data[2]=0x4d,data[3]=0x6f,data[4]=0x64,data[5]=0x65,data[6]=0x00);
    };
    interpret XF86_Prev_VMode+AnyOfOrNone(all) {
        repeat= True;
        action= Private(type=0x86,data[0]=0x2d,data[1]=0x56,data[2]=0x4d,data[3]=0x6f,data[4]=0x64,data[5]=0x65,data[6]=0x00);
    };

those bytes indicate some memory corruption. if you save the xkbcomp output
from a working version, then apply the option and replace the above part
from the working version, vt switching works again.

xkbcomp -xkb $DISPLAY working.xkb
setxkbmap -option "altwin:alt_super_win"
xkbcomp -xkb $DISPLAY broken.xkb
# copy the lines from working.xkb to broken.xkb
xkbcomp broken.xkb $DISPLAY

vt switch

(In reply to comment #17)
> xkbcomp -xkb $DISPLAY working.xkb
> setxkbmap -option "altwin:alt_super_win"
> xkbcomp -xkb $DISPLAY broken.xkb
> # copy the lines from working.xkb to broken.xkb
> xkbcomp broken.xkb $DISPLAY

just ran these commands on the current git master server and there was no difference besides the intended ones. Carl, are you still seeing this issue?

On Sun, Jul 11, 2010 at 10:56:04PM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #18 from Peter Hutterer <peter.hutterer@who-t.net> 2010-07-11 22:56:04 PDT ---
> (In reply to comment #17)
> > xkbcomp -xkb $DISPLAY working.xkb
> > setxkbmap -option "altwin:alt_super_win"
> > xkbcomp -xkb $DISPLAY broken.xkb
> > # copy the lines from working.xkb to broken.xkb
> > xkbcomp broken.xkb $DISPLAY
> 
> just ran these commands on the current git master server and there was no
> difference besides the intended ones. Carl, are you still seeing this issue?

'Twas fixed with 3711d68f657c77b947cc4670cc4eac4f62de3af8.

(In reply to comment #19)
> 'Twas fixed with 3711d68f657c77b947cc4670cc4eac4f62de3af8.

that's a fix to 1.6, Carl saw this issue with a 1.7RC. So somehow I don't think that was it.

Just doing a driveby here ...

(In reply to comment #17)
> nasty, nasty, nasty. looking at the output of xkbcomp before and after
> applying the option, the difference that's interesting is:
> 
>     interpret XF86_Ungrab+AnyOfOrNone(all) {
>         repeat= True;
>         action=
> Private(type=0x86,data[0]=0x55,data[1]=0x6e,data[2]=0x67,data[3]=0x72,data[4]=0x61,data[5]=0x62,data[6]=0x00);
>     };
>     [...]
> 
> those bytes indicate some memory corruption.

Actually not: 0x86 speaks for itself, whereas 0x6e,0x67,0x72,0x61,0x62 are 'Ungrab' in ASCII.  So that's fine.

Anyway, I can still reproduce this on master - very odd.

OK, so this gets a bit weird.  The problem comes with having RWIN mapped
to two modifiers; it looks like our vmod -> modifier map is flaky.
Simply modifying my current working keymap to have RWIN produce Alt_R
but be part of Mod4 is enough to break VT switching, even if the core
state produced is correct (sigh).

Changing the Alt_L+AnyOfOrNone(all) compatibility definition to use
SetMods(modifiers=Alt,clearLocks) rather than modifiers=modMapMods seems
to paper over the real problem, assuming you only use left Alt to switch
VTs.

(In reply to comment #22)
> OK, so this gets a bit weird.  The problem comes with having RWIN mapped
> to two modifiers; it looks like our vmod -> modifier map is flaky.
> Simply modifying my current working keymap to have RWIN produce Alt_R
> but be part of Mod4 is enough to break VT switching, even if the core
> state produced is correct (sigh).
> 
> Changing the Alt_L+AnyOfOrNone(all) compatibility definition to use
> SetMods(modifiers=Alt,clearLocks) rather than modifiers=modMapMods seems
> to paper over the real problem, assuming you only use left Alt to switch
> VTs.

Having bashed at this from the xkbcommon side of things, I'm fairly sure this is the actual problem (and not just a symptom) and changing the XKB data files will fix it.

Sergey, are you able to change all the compat interps to have an explicit modifiers= instead of relying on useModMapMods? This would be nice as I'm hoping to deprecate useModMapMods ...

> Sergey, are you able to change all the compat interps to have an explicit
> modifiers= instead of relying on useModMapMods? This would be nice as I'm
> hoping to deprecate useModMapMods ...
Daniel, let's try that. I see 18 cases where modMapMods are used. What should I change them to?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/15.