Bug 24094 - CTRL-ALT-F1 doesn't switch to VT1 (provides garbage input to terminal instead)
Summary: CTRL-ALT-F1 doesn't switch to VT1 (provides garbage input to terminal instead)
Status: NEW
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: xkb
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: xserver-1.13
  Show dependency treegraph
 
Reported: 2009-09-22 15:13 UTC by Carl Worth
Modified: 2012-04-05 20:06 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
My Xorg.0.log file (67.50 KB, text/plain)
2009-09-22 17:12 UTC, Carl Worth
Details
Output of "xkbcomp -xkb :0 -" (44.45 KB, text/plain)
2009-11-04 17:09 UTC, Carl Worth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Carl Worth 2009-09-22 15:13:43 UTC
Pressing CTRL-ALT-F1 emits ";7P" into my terminal rather than switching
to VT1 as I would expect.

Daniel Stone is sitting next to me and had me run the following which didn't help:

setxkbmap
setxkbmap -print | xkbcomp - :0

We also looked at the output of "xkbcomp -xkb :0 -" and xev, all of which left
Daniel with no clever answer as to what the problem could be.

I'm running git master, (as of Sep. 18 or so), of xserver and friends on top
of Debian unstable.

I'm gladly willing to experiment with anything that might provide additional
necessary information.

-Carl
Comment 1 Alan Coopersmith 2009-09-22 15:39:15 UTC
No insight to be gained from Xorg.0.log either?
Comment 2 Daniel Stone 2009-09-22 15:54:19 UTC
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.
Comment 3 Carl Worth 2009-09-22 17:12:31 UTC
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
Comment 4 Alan Coopersmith 2009-09-22 17:21:17 UTC
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 5 Peter Hutterer 2009-09-22 17:23:25 UTC
> --- 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
Comment 6 Peter Hutterer 2009-09-30 20:49:57 UTC
Any update on this? Is this still an issue? (I don't have the slightest clue what could be going on)
Comment 7 Peter Hutterer 2009-10-01 22:47:25 UTC
No update, moving to 1.7.1.
Comment 8 Carl Worth 2009-10-02 06:05:10 UTC
(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

Comment 9 Peter Hutterer 2009-10-04 20:43:09 UTC
(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 -)

Comment 10 Carl Worth 2009-11-04 17:08:13 UTC
(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
Comment 11 Carl Worth 2009-11-04 17:09:03 UTC
Created attachment 30973 [details]
Output of "xkbcomp -xkb :0 -"

Let me know what you see.

-Carl
Comment 12 Peter Hutterer 2009-11-04 17:33:24 UTC
(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.
Comment 13 Carl Worth 2009-12-10 10:51:58 UTC
(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
Comment 14 Carl Worth 2009-12-10 11:51:18 UTC
(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.
Comment 15 Peter Hutterer 2009-12-10 14:52:51 UTC
(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).
Comment 16 Carl Worth 2009-12-10 15:41:39 UTC
(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
Comment 17 Peter Hutterer 2009-12-10 19:45:05 UTC
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
Comment 18 Peter Hutterer 2010-07-11 22:56:04 UTC
(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?
Comment 19 Daniel Stone 2010-07-12 02:16:53 UTC
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.
Comment 20 Peter Hutterer 2010-07-14 18:50:18 UTC
(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.
Comment 21 Daniel Stone 2011-05-31 17:17:18 UTC
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.
Comment 22 Daniel Stone 2011-06-01 04:37:56 UTC
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.
Comment 23 Daniel Stone 2012-04-03 13:37:59 UTC
(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 ...
Comment 24 Sergey V. Udaltsov 2012-04-05 20:06:37 UTC
> 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?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.