[Fwd: Re: Since chvt works, the problem must be the keymap]
David Claughton
>
> It would be interesting to see which keycodes and keysyms are reported
> if you run "xev", press (and hold) both CTRL and ALT, and then press F1,
> F2, etc. Does xev really display the keycodes for the Fn keys and the
> keysyms "XF86_Switch_VT_n"? Are the hexadecimal keysym values the same
> as the ones that you get with "grep VT /usr/share/X11/XKeysymDB"?
>
As another "sufferer" of this problem I thought I would give this a try
- I get ...
KeyPress event, serial 29, synthetic NO, window 0x2600001,
root 0x3e, subw 0x0, time 1066810844, (622,696), root:(630,759),
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 29, synthetic NO, window 0x2600001,
root 0x3e, subw 0x0, time 1066810861, (622,696), root:(630,759),
state 0x14, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 29, synthetic NO, window 0x2600001,
root 0x3e, subw 0x0, time 1066815357, (622,696), root:(630,759),
state 0x1c, keycode 67 (keysym 0xffbe, F1), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 29, synthetic NO, window 0x2600001,
root 0x3e, subw 0x0, time 1066815411, (622,696), root:(630,759),
state 0x1c, keycode 67 (keysym 0xffbe, F1), same_screen YES,
XLookupString gives 0 bytes:
KeyRelease event, serial 29, synthetic NO, window 0x2600001,
root 0x3e, subw 0x0, time 1066816162, (622,696), root:(630,759),
state 0x1c, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
KeyRelease event, serial 29, synthetic NO, window 0x2600001,
root 0x3e, subw 0x0, time 1066816188, (622,696), root:(630,759),
state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
And "grep VT /usr/share/X11/XKeysymDB" returns :
XF86_Switch_VT_1 :1008FE01
XF86_Switch_VT_2 :1008FE02
XF86_Switch_VT_3 :1008FE03
XF86_Switch_VT_4 :1008FE04
XF86_Switch_VT_5 :1008FE05
XF86_Switch_VT_6 :1008FE06
XF86_Switch_VT_7 :1008FE07
XF86_Switch_VT_8 :1008FE08
XF86_Switch_VT_9 :1008FE09
XF86_Switch_VT_10 :1008FE0A
XF86_Switch_VT_11 :1008FE0B
XF86_Switch_VT_12 :1008FE0C
Does this tell anyone anything?
Dave.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Claughton
Sorry, sorry - first I reply directly to Florian by mistake, then I try
to correct that and end up screwing up the Subject and threading. I
must be getting tired :-)
Florian Kulzer
I think that is part of the problem: Even though you hold down CTRL and
ALT before you press F1, you still get the normal "F1" keysymbol and not
the "XF86_Switch_VT_1" one. If I run "xev" and press the three keys then
I never see the KeyPress event for F1 because X switches to the
terminal. If, on the other hand, I disable VT switching in my xorg.conf
then I still do not get any event for F1 if I press it while CTRL + ALT
are held down. Something within X obviously intercepts these events and
processes them or deletes them from the event queue, depending on the
settings in xorg.conf.
[ snip: we see the expected three KeyRelease events ]
> And "grep VT /usr/share/X11/XKeysymDB" returns :
>
> XF86_Switch_VT_1 :1008FE01
[...]
I have the same here.
> Does this tell anyone anything?
Check what is assigned to keycode 67. I see this:
$ xmodmap -pk | egrep '^[ ]+67 '
67 0xffbe (F1) 0x1008fe01 (XF86_Switch_VT_1)
If your output looks different then you can try if
xmodmap -e 'keycode 67 = F1 XF86_Switch_VT_1'
restores the VT switching.
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
Amy Templeton
> Check what is assigned to keycode 67. I see this:
> $ xmodmap -pk | egrep '^[ ]+67 '
> 67 0xffbe (F1) 0x1008fe01 (XF86_Switch_VT_1)
> If your output looks different then you can try if
> xmodmap -e 'keycode 67 = F1 XF86_Switch_VT_1'
> restores the VT switching.
Well, I've got what seems to be the correct output. Also,
xev seems to read things fine from what I can tell. I would
be glad to provide the exact output if it would be helpful.
Thanks,
Amy
Florian Kulzer
> Florian Kulzer wrote:
> > Check what is assigned to keycode 67. I see this:
>
> > $ xmodmap -pk | egrep '^[ ]+67 '
> > 67 0xffbe (F1) 0x1008fe01 (XF86_Switch_VT_1)
>
> > If your output looks different then you can try if
>
> > xmodmap -e 'keycode 67 = F1 XF86_Switch_VT_1'
>
> > restores the VT switching.
>
> Well, I've got what seems to be the correct output. Also,
> xev seems to read things fine from what I can tell. I would
> be glad to provide the exact output if it would be helpful.
At the moment it seems to me that we have checked all the common
pitfalls and still we have no clue why VT switching does not work for
you. Pretty much all that we can do now is poke at a few more things and
hope that a hint comes up. I am now simply very curious what events are
reported when you press CTR + ALT + F1. The KeyPress events for CTRL and
ALT should harbor no surprises, but what happens with F1? Is it reported
as keysym "F1", is it recognized as keysym "XF86_Switch_VT_1" or is it
swallowed by X?
I would also suggest that you check the end /var/log/Xorg.0.log right
after you try to switch VTs. I see these new lines in the log after I
switch to tty1 with CTRL + ALT + F1:
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(II) intel(0): xf86UnbindGARTMemory: unbind key 1
(II) intel(0): xf86UnbindGARTMemory: unbind key 2
(II) intel(0): xf86UnbindGARTMemory: unbind key 3
(II) intel(0): xf86UnbindGARTMemory: unbind key 4
Maybe your VT switching is indeed blocked by a problem with the graphics
driver as suggested earlier by cga. In that case I would hope that the
log will give us a hint what to do about it.
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
cga2000
Normally, that would have been my first reaction to the problem. But
then this was some 4-5 years ago and I can't be sure I looked .. or if
I saw anything.
Also, I'm not sure the behavior of xev is to be relied upon in this
case. From a totally non-technical standpoint, it could be that when
CTRL+Alt+Fn "works" as intended, xev never gets to "see" it .. and otoh,
when it does not, the keycode gets passed to xev. If you follow my
general train of thought.
If I was experiencing such a problem at this point I think I would
subscribe to one of the X.org mailing lists. They are clearly meant for
developers only and these folks may very well not be willing to deal
with us mortals .. but then they should be able to tell us where to go
to try and figure out what this problem is ..
worth a try?
Thanks,
cga
David Claughton
> Check what is assigned to keycode 67. I see this:
>
> $ xmodmap -pk | egrep '^[ ]+67 '
> 67 0xffbe (F1) 0x1008fe01 (XF86_Switch_VT_1)
>
> If your output looks different then you can try if
>
> xmodmap -e 'keycode 67 = F1 XF86_Switch_VT_1'
>
> restores the VT switching.
>
This does seem to be the answer, or nearly at least ...
david@debian:~$ xmodmap -pk | egrep '^[ ]+67 '
67 0xffbe (F1) 0xffca (F13)
This is wrong, so I run the second command ...
david@debian:~$ xmodmap -e 'keycode 67 = F1 XF86_Switch_VT_1'
david@debian:~$ xmodmap -pk | egrep '^[ ]+67 '
67 0xffbe (F1) 0x1008fe01 (XF86_Switch_VT_1)
This now allows me to switch VT on pressing Shift-F1, but not on
Ctrl-Alt-F1. Checking the xmodmap man page reveals that this is correct
- the command maps keycode = keysym shifted-keysym.
However despite careful reading of the man page and a bit of googling,
I'm not sure of the correct way to get the XF86_Switch_VT_1 keysym onto
Ctrl-Alt-F1 where it belongs?
Thanks, Dave.
Amy Templeton
sudoers manual, and added the following to the line for my
username to the system /etc/sudoers file (using visudo, of
course):
Code:
_______________________
NOPASSWD: /usr/bin/chvt
_______________________
...which allows me to successfully invoke chvt without
entering a password. I then added the following stanzas to
my ~/.xmodmap file:
Code:
_____________________
"sudo chvt 1"
control + Mod1 + F1
"sudo chvt 2"
control + Mod1 + F2
"sudo chvt 3"
control + Mod1 + F3
"sudo chvt 4"
control + Mod1 + F4
"sudo chvt 5"
control + Mod1 + F5
"sudo chvt 6"
control + Mod1 + F6
_____________________
...which allows me to switch to a VT using control-alt-f#!
Sweet! Mission accomplished! Thanks for the help of everyone
here.
However, there is one small hitch: when invoked from a
commandline, chvt takes me to a VT. There, I can log in,
move to another VT with Alt-f#, or go back to X with alt-f7.
However, when invoked via a keybinding, chvt takes me to the
correct VT, from which I can either log in or go back to X
with alt-f7. If, however, I try to change to another VT from
there, it flashes over to it for a second and then switches
back. This also happens if I invoke chvt from the VT. Unless
somebody has an immediately obvious fix for this, however,
I'm willing to live with this, since the fix above is
admittedly treating the symptoms but not so much the
problem.
Anyway, thanks again to everyone.
Amy
Florian Kulzer
> Florian Kulzer wrote:
>> Check what is assigned to keycode 67. I see this:
>> $ xmodmap -pk | egrep '^[ ]+67 '
>> 67 0xffbe (F1) 0x1008fe01 (XF86_Switch_VT_1)
>> If your output looks different then you can try if
>> xmodmap -e 'keycode 67 = F1 XF86_Switch_VT_1'
>> restores the VT switching.
>
> This does seem to be the answer, or nearly at least ...
>
> david@debian:~$ xmodmap -pk | egrep '^[ ]+67 '
> 67 0xffbe (F1) 0xffca (F13)
>
> This is wrong, so I run the second command ...
>
> david@debian:~$ xmodmap -e 'keycode 67 = F1 XF86_Switch_VT_1'
> david@debian:~$ xmodmap -pk | egrep '^[ ]+67 '
> 67 0xffbe (F1) 0x1008fe01 (XF86_Switch_VT_1)
>
> This now allows me to switch VT on pressing Shift-F1, but not on
> Ctrl-Alt-F1. Checking the xmodmap man page reveals that this is correct -
> the command maps keycode = keysym shifted-keysym.
That is interesting. "keycode 67 = F1 XF86_Switch_VT_1" is the output that I
get with "xmodmap -pke" and this command is supposed to return the exact
expressions which can be used with "-e" to set things up. I can only guess that
the format of the expressions is dependent on the general keyboard setup.
> However despite careful reading of the man page and a bit of googling, I'm
> not sure of the correct way to get the XF86_Switch_VT_1 keysym onto
> Ctrl-Alt-F1 where it belongs?
I would experiment like this:
xmodmap -e 'keycode 67 = F1 F13 XF86_Switch_VT_1'
xmodmap -e 'keycode 67 = F1 F13 F1 XF86_Switch_VT_1'
xmodmap -e 'keycode 67 = F1 F1 F1 XF86_Switch_VT_1'
xmodmap -e 'keycode 67 = F1 F13 F13 XF86_Switch_VT_1'
It would be interesting to know what works for you and also your general
keyboard setup. For comparison, here is what I have:
$ xmodmap -pke | grep 'F1 '
keycode 67 = F1 XF86_Switch_VT_1
$ setxkbmap -print
xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete+caps(shift)" };
xkb_compat { include "complete" };
xkb_symbols { include "pc(pc105)+es(nodeadkeys)+compose(menu)" };
xkb_geometry { include "pc(pc105)" };
};
$ awk '/Section "InputDevice"/,/EndSection/' /etc/X11/xorg.conf
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "es"
Option "XkbVariant" "nodeadkeys"
EndSection
[ snip: output related to the mouse ]
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
David Claughton
> I would experiment like this:
>
> xmodmap -e 'keycode 67 = F1 F13 XF86_Switch_VT_1'
> xmodmap -e 'keycode 67 = F1 F13 F1 XF86_Switch_VT_1'
> xmodmap -e 'keycode 67 = F1 F1 F1 XF86_Switch_VT_1'
> xmodmap -e 'keycode 67 = F1 F13 F13 XF86_Switch_VT_1'
Nope, none of these commands seem to work - all possible
shift/alt/control F1 combinations I tried after running each of these
commands just got me an error beep + a letter or two on the terminal,
or it launched Gnome Help!
> It would be interesting to know what works for you and also your general
> keyboard setup. For comparison, here is what I have:
>
> $ xmodmap -pke | grep 'F1 '
> keycode 67 = F1 XF86_Switch_VT_1
>
I get the same ...
> $ setxkbmap -print
> xkb_keymap {
> xkb_keycodes { include "xfree86+aliases(qwerty)" };
> xkb_types { include "complete+caps(shift)" };
> xkb_compat { include "complete" };
> xkb_symbols { include "pc(pc105)+es(nodeadkeys)+compose(menu)" };
> xkb_geometry { include "pc(pc105)" };
> };
>
I get ...
xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc(pc105)+uk" };
xkb_geometry { include "pc(pc105)" };
};
> $ awk '/Section "InputDevice"/,/EndSection/' /etc/X11/xorg.conf
> Section "InputDevice"
> Identifier "Generic Keyboard"
> Driver "kbd"
> Option "CoreKeyboard"
> Option "XkbRules" "xorg"
> Option "XkbModel" "pc105"
> Option "XkbLayout" "es"
> Option "XkbVariant" "nodeadkeys"
> EndSection
>
> [ snip: output related to the mouse ]
>
I get this ...
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "uk"
EndSection
So AFAICT, not a lot of help there.
I should also mention that once I have switched VT using Shift-F1, I can
switch back using Ctrl-Alt-F7 as expected - which seems to suggest
nothing is wrong with the system keymap.
Dave.
Florian Kulzer
> Florian Kulzer wrote:
>
>> I would experiment like this:
>> xmodmap -e 'keycode 67 = F1 F13 XF86_Switch_VT_1'
>> xmodmap -e 'keycode 67 = F1 F13 F1 XF86_Switch_VT_1'
>> xmodmap -e 'keycode 67 = F1 F1 F1 XF86_Switch_VT_1'
>> xmodmap -e 'keycode 67 = F1 F13 F13 XF86_Switch_VT_1'
>
> Nope, none of these commands seem to work - all possible shift/alt/control
> F1 combinations I tried after running each of these commands just got me an
> error beep + a letter or two on the terminal, or it launched Gnome Help!
So much for that brilliant theory...
[...]
>> $ setxkbmap -print
[...]
> xkb_keymap {
> xkb_keycodes { include "xfree86+aliases(qwerty)" };
> xkb_types { include "complete" };
> xkb_compat { include "complete" };
> xkb_symbols { include "pc(pc105)+uk" };
> xkb_geometry { include "pc(pc105)" };
> };
[...]
> Section "InputDevice"
> Identifier "Generic Keyboard"
> Driver "kbd"
> Option "CoreKeyboard"
> Option "XkbRules" "xorg"
> Option "XkbModel" "pc105"
> Option "XkbLayout" "uk"
> EndSection
>
>
> So AFAICT, not a lot of help there.
>
> I should also mention that once I have switched VT using Shift-F1, I can
> switch back using Ctrl-Alt-F7 as expected - which seems to suggest nothing
> is wrong with the system keymap.
There are two different keymaps: The console keymap (which seems to be
OK) and the X keymap (which we cannot quite figure out, it seems). The
VT switching mechanism is different once you are outside of X. This is
also the reason why it is enough to press ALT + Fn (no CTRL) to switch
VTs once you are on a non-X tty.
I am afraid it is time to start grasping at straws now:
- try "gb" instead of "uk" for XkbLayout
and/or
- try "pc104" instead of "pc105" for XkbModel
and/or
- add this to the keyboard section:
Option "Xkbdisable" "true"
Restart X and see if any of it helps.
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
cga2000
> On Wed, May 02, 2007 at 00:49:38 +0100, David Claughton wrote:
> > Florian Kulzer wrote:
> >
> >> I would experiment like this:
> >> xmodmap -e 'keycode 67 = F1 F13 XF86_Switch_VT_1'
> >> xmodmap -e 'keycode 67 = F1 F13 F1 XF86_Switch_VT_1'
> >> xmodmap -e 'keycode 67 = F1 F1 F1 XF86_Switch_VT_1'
> >> xmodmap -e 'keycode 67 = F1 F13 F13 XF86_Switch_VT_1'
> >
> > Nope, none of these commands seem to work - all possible shift/alt/control
> > F1 combinations I tried after running each of these commands just got me an
> > error beep + a letter or two on the terminal, or it launched Gnome Help!
>
> So much for that brilliant theory...
It's certainly the one that makes the better sense.
At least it's something I can understand.
To be a little more precise .. it looks as if there are two totally
separate mechanisms... One that's "system-wide" so to speak .. handled
by the kernel .. (?) .. manages VT's wherever you are .. including in
an X session .. and whatever they are currently connected with including
"nothing" .. lets you switch .. but also create & destroy VT's on the
fly (man chvt). And then there's another mechanism that works only when
you are running an X session .. only lets you switch VT's .. and is
presumably handled by the X server.
No idea if the two are related or how..
> This is also the reason why it is enough to press ALT + Fn (no CTRL)
> to switch VTs once you are on a non-X tty.
> I am afraid it is time to start grasping at straws now:
>
> - try "gb" instead of "uk" for XkbLayout
>
> and/or
>
> - try "pc104" instead of "pc105" for XkbModel
>
> and/or
>
> - add this to the keyboard section:
> Option "Xkbdisable" "true"
>
> Restart X and see if any of it helps.
The other (vague I admit) reason I mentioned buggy video drivers as a
possible cause is that though I was not able to verify this first-hand
.. I did see in google instances of folks reporting they has fixed such
a problem being fixed by upgrading their X driver to a more current
version. But since both those who experienced the problem and those who
came up with the "solution" were just as clueless as myself as to what
would be causing this .. it mostly ran along the lines of .. ".. works
here with the 3.99 version .. what're you running .. 3.72.3 .. hmm..
you may want to try to upgrade" .. "you're my hero .. thanks a ton ..
upgraded the driver and it took care of the problem."
Thanks,
cga
David Claughton
> I am afraid it is time to start grasping at straws now:
>
> - try "gb" instead of "uk" for XkbLayout
>
Well, would you believe it - that fixed the problem!
I still can't quite believe it was as simple as that.
Thanks a lot for your help :-)
Dave.
Florian Kulzer
> Florian Kulzer wrote:
> > I am afraid it is time to start grasping at straws now:
>> - try "gb" instead of "uk" for XkbLayout
>
> Well, would you believe it - that fixed the problem!
>
> I still can't quite believe it was as simple as that.
>
> Thanks a lot for your help :-)
Well, in retrospect it is obvious that we should have had a good look at
your xorg.conf and your logfile first. You joined this thread when we
were already completely fixated on solving the ultimate mystery of the
keysyms and therefore we could not see the forest for the tress anymore,
I guess.
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
Florian Kulzer
> On Wed, May 02, 2007 at 09:27:35AM EDT, Florian Kulzer wrote:
> > On Wed, May 02, 2007 at 00:49:38 +0100, David Claughton wrote:
> > > Florian Kulzer wrote:
> > >
> > >> I would experiment like this:
> > >> xmodmap -e 'keycode 67 = F1 F13 XF86_Switch_VT_1'
> > >> xmodmap -e 'keycode 67 = F1 F13 F1 XF86_Switch_VT_1'
> > >> xmodmap -e 'keycode 67 = F1 F1 F1 XF86_Switch_VT_1'
> > >> xmodmap -e 'keycode 67 = F1 F13 F13 XF86_Switch_VT_1'
> > >
> > > Nope, none of these commands seem to work - all possible shift/alt/control
> > > F1 combinations I tried after running each of these commands just got me an
> > > error beep + a letter or two on the terminal, or it launched Gnome Help!
> >
> > So much for that brilliant theory...
>
> It's certainly the one that makes the better sense.
>
> At least it's something I can understand.
I think I understand now why it did not work: There is more to this
keysym business than what meets the eye in the output of the xmodmap
commands as we have used them in this thread. Besides their symbols the
keys also have a "type" assigned to them and this type determines how
the additional keysyms are interpreted. The function keys should
normally be of type "CTRL+ALT" which means what the name suggests: They
always produce "Fn" except when used with CTRL and ALT together, in
which case the second keysym is registered. This type is defined here:
$ awk '/CTRL\+ALT/,/};/' /usr/share/X11/xkb/types/pc
type "CTRL+ALT" {
modifiers = Control+Alt;
map[Control+Alt] = Level2;
level_name[Level1] = "Base";
level_name[Level2] = "Ctrl+Alt";
};
In David's case it turned out that he had the obsolete "uk" layout in
his xorg.conf instead of "gb" and because of this his X obviously did
not load the correct type definitions. Therefore he could only activate
the VT switching for SHIFT + F1.
If you specify an existing layout from /usr/share/X11/xkb/symbols/ then
everything seems to be taken care of by the "pc" file in that directory:
$ awk '/<FK01>/,/};/' /usr/share/X11/xkb/symbols/pc
key <FK01> {
type="CTRL+ALT",
symbols[Group1]= [ F1, XF86_Switch_VT_1 ]
};
[...]
> > > I should also mention that once I have switched VT using Shift-F1, I can
> > > switch back using Ctrl-Alt-F7 as expected - which seems to suggest nothing
> > > is wrong with the system keymap.
> >
> > There are two different keymaps: The console keymap (which seems to be
> > OK) and the X keymap (which we cannot quite figure out, it seems). The
> > VT switching mechanism is different once you are outside of X.
>
> To be a little more precise .. it looks as if there are two totally
> separate mechanisms... One that's "system-wide" so to speak .. handled
> by the kernel .. (?) .. manages VT's wherever you are .. including in
> an X session .. and whatever they are currently connected with including
> "nothing" .. lets you switch .. but also create & destroy VT's on the
> fly (man chvt). And then there's another mechanism that works only when
> you are running an X session .. only lets you switch VT's .. and is
> presumably handled by the X server.
>
> No idea if the two are related or how..
[...]
> The other (vague I admit) reason I mentioned buggy video drivers as a
> possible cause is that though I was not able to verify this first-hand
> .. I did see in google instances of folks reporting they has fixed such
> a problem being fixed by upgrading their X driver to a more current
> version. But since both those who experienced the problem and those who
> came up with the "solution" were just as clueless as myself as to what
> would be causing this .. it mostly ran along the lines of .. ".. works
> here with the 3.99 version .. what're you running .. 3.72.3 .. hmm..
> you may want to try to upgrade" .. "you're my hero .. thanks a ton ..
> upgraded the driver and it took care of the problem."
I think these are all good points. We definitely have to use the next
person with this problem as our guinea pig to experiment a bit more in
that direction ;)
P.S. David, I included the information about types and keysyms in this
mail rather than in my last response to you because the quoted
older messages here made it easier for me to have the complete
story in one mail.
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
David Claughton
> I think I understand now why it did not work: There is more to this
> keysym business than what meets the eye ... [snipped very informative explanation]
Great work, Florian! I always find it fascinating when I get a glimpse
into how something works "under the covers".
FWIW, I can confirm I have no 'uk' symbols file in the directory you
quoted. I can only imagine that one existed when I first installed
Debian on this machine (which would have been just after the Sarge
release IIRC), and it has since been replaced by the 'gb' one. I'm just
guessing though.
Thanks again,
Dave.
Andrew Sackville-West
> On Thu, May 03, 2007 at 00:41:32 +0100, David Claughton wrote:
> > Florian Kulzer wrote:
> > > I am afraid it is time to start grasping at straws now:
> >> - try "gb" instead of "uk" for XkbLayout
> >
> > Well, would you believe it - that fixed the problem!
> >
> > I still can't quite believe it was as simple as that.
> >
> > Thanks a lot for your help :-)
>
> Well, in retrospect it is obvious that we should have had a good look at
> your xorg.conf and your logfile first. You joined this thread when we
> were already completely fixated on solving the ultimate mystery of the
> keysyms and therefore we could not see the forest for the tress anymore,
> I guess.
is Amy still lurking on this thread??? is there something missing in
your xorg.conf?
A
Amy Templeton
I'm still around. I guess you missed my quick workaround the
other day (thanks to the magics of xbindkeys, sudo, and
chvt). However, if there is an alternative to "us" that you
think might fix the problem if given as an argument to
"XkbLayout," I'd certainly be glad to try it. GB settings
are somewhat useless to me, I'm afraid, since I'm from the
US. Thanks, though.
Amy
P.S.: When did the thread title get changed, anyway? I
guess I missed that.
David Claughton
Amy Templeton wrote:
>
> P.S.: When did the thread title get changed, anyway? I
> guess I missed that.
>
If you mean the 'SOLVED' tag, I'm afraid that'd be me. I guess I'd
forgotton I was riding on your thread, I probably
shouldn't have implied that the entire issue was resolved. Sorry.
Dave.
--
View this message in context: http://www.nabble.com/-Fwd%3A-Re%3A-Since-chvt-works%2C-the-problem-must-be-the-keymap--tf3667109.html#a10319222
Sent from the Debian User mailing list archive at Nabble.com.
Amy Templeton
> Amy Templeton wrote:
> >
> > P.S.: When did the thread title get changed, anyway? I
> > guess I missed that.
> >
> If you mean the 'SOLVED' tag, I'm afraid that'd be me. I guess I'd
> forgotton I was riding on your thread, I probably
> shouldn't have implied that the entire issue was resolved. Sorry.
Actually, I meant from "Oh! Also, can't get to VT" or
whatever it was originally. I also attached a [solved] tag
to it at some point. No worries. :-)
Amy
Florian Kulzer
> Andrew Sackville-West wrote:
> > On Thu, May 03, 2007 at 10:09:42PM +0200, Florian Kulzer wrote:
> > > On Thu, May 03, 2007 at 00:41:32 +0100, David Claughton wrote:
> > > > Florian Kulzer wrote:
> > > > > I am afraid it is time to start grasping at straws now:
> > > >> - try "gb" instead of "uk" for XkbLayout
> > > >
> > > > Well, would you believe it - that fixed the problem!
> > > >
> > > > I still can't quite believe it was as simple as that.
> > > >
> > > > Thanks a lot for your help :-)
> > >
> > > Well, in retrospect it is obvious that we should have had a good look at
> > > your xorg.conf and your logfile first. You joined this thread when we
> > > were already completely fixated on solving the ultimate mystery of the
> > > keysyms and therefore we could not see the forest for the tress anymore,
> > > I guess.
> >
> > is Amy still lurking on this thread??? is there something
> > missing in your xorg.conf?
>
> I'm still around. I guess you missed my quick workaround the
> other day (thanks to the magics of xbindkeys, sudo, and
> chvt). However, if there is an alternative to "us" that you
> think might fix the problem if given as an argument to
> "XkbLayout," I'd certainly be glad to try it. GB settings
> are somewhat useless to me, I'm afraid, since I'm from the
> US. Thanks, though.
What do you see if you disable your workaround, run
tail -fn0 /var/log/Xorg.0.log
and press CTRL+ALT+F1? If you get some errors or warnings related to
switching graphics modes then we know that the key combination does work
after all and that there is a problem with the graphics driver. If there
is no output at all then we know that your keysyms are still not set up
correctly.
(My apologies if we went over this already. I have now totally lost
track of the various branches of this thread.)
It might also be illuminating to try if the switching works with the
"gb" layout even if this layout is not an acceptable permanent solution.
This might at least provide an opportunity to revive the "color vs.
colour" thread that we had a while back...
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
Amy Templeton
> (My apologies if we went over this already. I have now totally lost
> track of the various branches of this thread.)
It's okay. Also, appreciated.
> tail -fn0 /var/log/Xorg.0.log
> and press CTRL+ALT+F1?
Well...if I do that while I'm still in the XTerm, I see...
^[[1;7P
...but I think that's just XTerm freaking out. When another frame
is focused and I press the buttons, there is no output.
> If you get some errors or warnings related to switching graphics
> modes then we know that the key combination does work after all
> and that there is a problem with the graphics driver. If there is
> no output at all then we know that your keysyms are still not set
> up correctly.
It appears, then, to be the latter.
> It might also be illuminating to try if the switching works with
> the "gb" layout even if this layout is not an acceptable
> permanent solution.
Well, that's interesting. It did work properly using the "gb"
layout (though it took me a while to figure that out, since I
thought the keyboard wasn't working at all, but it turns out there
were just some problems until I disabled my xmodmap). That's very
weird.
One thing that I saw in the startx output using the "gb" layout
that I definitely do *not* see under the "us" layout was the
following...
CODE:
___________________________
SetGrabKeysState - disabled
___________________________
...upon switching to the console, and...
CODE:
__________________________
SetGrabKeysState - enabled
__________________________
...upon switching back to X. Is this inspiring at all?
> This might at least provide an opportunity to revive the "color
> vs. colour" thread that we had a while back...
Oh dear...and that of course brings up "gray vs. grey," "center vs.
centre," "boot vs. trunk," and all those other bizarre little
spelling differences that don't actually make a difference in
pronunciation ("boot" is *totally* still pronounced "trunk" in GB,
I swear).
Anyway...
Thanks,
Amy
--
Measure twice, cut once.
Andrew Sackville-West
> Florian Kulzer <florian.ku...@icfo.es> wrote:
>
> > What do you see if you disable your workaround, run
>
> > tail -fn0 /var/log/Xorg.0.log
>
> > and press CTRL+ALT+F1?
>
> Well...if I do that while I'm still in the XTerm, I see...
>
> ^[[1;7P
that's not good. THat means X is ignoring those keystrokes and passing
them through to Xterm.
>
> ...but I think that's just XTerm freaking out. When another frame
> is focused and I press the buttons, there is no output.
the other frames provide no output because thety are ignoring
key-presses they don't know how to deal with, I assume.
>
> > If you get some errors or warnings related to switching graphics
> > modes then we know that the key combination does work after all
> > and that there is a problem with the graphics driver. If there is
> > no output at all then we know that your keysyms are still not set
> > up correctly.
>
> It appears, then, to be the latter.
>
> > It might also be illuminating to try if the switching works with
> > the "gb" layout even if this layout is not an acceptable
> > permanent solution.
>
> Well, that's interesting. It did work properly using the "gb"
> layout (though it took me a while to figure that out, since I
> thought the keyboard wasn't working at all, but it turns out there
> were just some problems until I disabled my xmodmap). That's very
> weird.
what happens when you disable your xmodmap with a "us" layout?
>
> One thing that I saw in the startx output using the "gb" layout
> that I definitely do *not* see under the "us" layout was the
> following...
are you seeing this on the VT you launched X from or is it in the
logs?
>
> CODE:
> ___________________________
>
> SetGrabKeysState - disabled
> ___________________________
>
> ...upon switching to the console, and...
>
> CODE:
> __________________________
>
> SetGrabKeysState - enabled
> __________________________
>
> ...upon switching back to X. Is this inspiring at all?
>
> > This might at least provide an opportunity to revive the "color
> > vs. colour" thread that we had a while back...
>
> Oh dear...and that of course brings up "gray vs. grey," "center vs.
> centre," "boot vs. trunk," and all those other bizarre little
> spelling differences that don't actually make a difference in
> pronunciation ("boot" is *totally* still pronounced "trunk" in GB,
> I swear).
I love how the spell "kitchen sheers" in the uk:
"kitchen-cester-sheers"
A
Amy Templeton
> On Tue, May 08, 2007 at 11:40:02PM -0400, Amy Templeton wrote:
> > Florian Kulzer <florian.ku...@icfo.es> wrote:
> >
> > > What do you see if you disable your workaround, run
> >
> > > tail -fn0 /var/log/Xorg.0.log
> >
> > > and press CTRL+ALT+F1?
> >
> > Well...if I do that while I'm still in the XTerm, I see...
> >
> > ^[[1;7P
> that's not good. THat means X is ignoring those keystrokes and
> passing them through to Xterm.
> > ...but I think that's just XTerm freaking out. When another
> > frame is focused and I press the buttons, there is no output.
> the other frames provide no output because thety are ignoring
> key-presses they don't know how to deal with, I assume.
That seems about right, yeah.
> > One thing that I saw in the startx output using the "gb" layout
> > that I definitely do *not* see under the "us" layout was the
> > following...
> are you seeing this on the VT you launched X from or is it in the
> logs?
On the VT.
> > > If you get some errors or warnings related to switching
> > > graphics modes then we know that the key combination does
> > > work after all and that there is a problem with the graphics
> > > driver. If there is no output at all then we know that your
> > > keysyms are still not set up correctly.
> >
> > It appears, then, to be the latter.
> >
> > > It might also be illuminating to try if the switching works
> > > with the "gb" layout even if this layout is not an acceptable
> > > permanent solution.
> >
> > Well, that's interesting. It did work properly using the "gb"
> > layout (though it took me a while to figure that out, since I
> > thought the keyboard wasn't working at all, but it turns out
> > there were just some problems until I disabled my xmodmap).
> > That's very weird.
> what happens when you disable your xmodmap with a "us" layout?
Oh dear...this is disturbing...it works properly. But...but...I
need to have Control where Caps Lock used to be, and I don't even
touch left-Alt! If xmodmap is the culprit, I'm afraid I'm just
going to have to deal with the problem. But at least, thanks to
you, the source of the problem has been found. Maybe I'll go
through at some point and comment out small portions at a time so I
can isolate the nefarious line(s) in question. But for now, I am
going to finish up the paper I'm ostensibly working on (no more
distracting self with email) and go to bed.
Thanks to all who've replied,
Amy
--
I can resist everything except temptation. -Oscar Wilde
Thomas Dickey
> that's not good. THat means X is ignoring those keystrokes and passing
> them through to Xterm.
Fortunately, "X" ignores keystrokes, so you're able to use your keyboard.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Thomas Dickey
>> and press CTRL+ALT+F1?
> Well...if I do that while I'm still in the XTerm, I see...
> ^[[1;7P
> ...but I think that's just XTerm freaking out. When another frame
> is focused and I press the buttons, there is no output.
It helps to read the documentation -
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Andrew Sackville-West
> Andrew Sackville-West <and...@farwestbilliards.com> wrote:
>
> > what happens when you disable your xmodmap with a "us" layout?
>
> Oh dear...this is disturbing...it works properly. But...but...I
> need to have Control where Caps Lock used to be, and I don't even
> touch left-Alt! If xmodmap is the culprit, I'm afraid I'm just
> going to have to deal with the problem. But at least, thanks to
> you, the source of the problem has been found. Maybe I'll go
> through at some point and comment out small portions at a time so I
> can isolate the nefarious line(s) in question. But for now, I am
> going to finish up the paper I'm ostensibly working on (no more
> distracting self with email) and go to bed.
Does this mean the problem is "solved"?
If so, then yes, its jsut a matter of figuring out what's not
compatible in your xmodmap and fixing it up.
A
Andrew Sackville-West
> Amy Templeton <amy.g.t...@gmail.com> wrote:
> >> and press CTRL+ALT+F1?
>
> > Well...if I do that while I'm still in the XTerm, I see...
>
> > ^[[1;7P
>
> > ...but I think that's just XTerm freaking out. When another frame
> > is focused and I press the buttons, there is no output.
>
> It helps to read the documentation -
>
> http://invisible-island.net/xterm/ctlseqs/ctlseqs.html
come on. Its not like this is slashdot or someth... oh. nm.
A
Amy Templeton
Oh...the [Solved] is a holdover from the first time it got
"solved." It just never got removed. Sorry for the confusion. But
it's solved enough for me, for the moment.
Amy
--
... the flaw that makes perfection perfect.
Andrew Sackville-West
> Andrew Sackville-West <and...@farwestbilliards.com> wrote:
> > On Wed, May 09, 2007 at 01:00:19AM -0400, Amy Templeton wrote:
> > > Andrew Sackville-West <and...@farwestbilliards.com> wrote:
> > >
> > > > what happens when you disable your xmodmap with a "us" layout?
> > >
> > > Oh dear...this is disturbing...it works properly. But...but...I
> > > need to have Control where Caps Lock used to be, and I don't
> > > even touch left-Alt! If xmodmap is the culprit, I'm afraid I'm
> > > just going to have to deal with the problem. But at least,
> > > thanks to you, the source of the problem has been found. Maybe
> > > I'll go through at some point and comment out small portions at
> > > a time so I can isolate the nefarious line(s) in question. But
> > > for now, I am going to finish up the paper I'm ostensibly
> > > working on (no more distracting self with email) and go to bed.
>
> > Does this mean the problem is "solved"?
>
> > If so, then yes, its jsut a matter of figuring out what's not
> > compatible in your xmodmap and fixing it up.
>
> Oh...the [Solved] is a holdover from the first time it got
> "solved." It just never got removed. Sorry for the confusion. But
> it's solved enough for me, for the moment.
I meant that the xmodmap was the problem, and without it your vt
switching functioned properly, right? So now its a "how do I fix my
xmodmap" question...
A
Amy Templeton
Oh. Well, in that case, yes. I figure that part shouldn't be too
hard; I'll just comment out everything, start X, switch to a VT,
kill X, uncomment something, start X, switch to a VT...etc. When I
have time, that is.
Anyway, thanks for your help in this!
Amy
--
Darth Vader! Only you would be so bold!
-- Princess Leia Organa