Re: Caps-Lock / NumLock-Problem
Elias Gerber <egerber@gmx.net> writes:
>On Sat, 2008-02-16 at 00:20 +0100, Helmut Waitzmann wrote:
>> Was sagt denn das Kommando
>>
>> $ xmodmap -pm
>
>elirips@XERXES:~$ xmodmap -pm
>xmodmap: up to 3 keys per modifier, (keycodes in parentheses):
>
>shift Shift_L (0x32), Shift_R (0x3e)
>lock Caps_Lock (0x42)
>control Control_L (0x25), Control_R (0x6d)
>mod1 Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c)
>mod2 Num_Lock (0x4d)
>mod3
>mod4 Super_L (0x7f), Hyper_L (0x80)
>mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x71),
>ISO_Level3_Shift (0x7c)
>
>> ? Sind da vielleicht mehrere Tasten, die eigentlich Unterschiedliches
>> bewirken sollen, dem selben modifier (erste Spalte der Ausgabe des
>> Kommandos) zugeordnet?
>
>Ich glaube nicht (?)
Du hast recht. Überschneidungen gibt es nur bei den Alt- und den
Meta-Tasten und bei den Super- und den Hyper-Tasten. Aber das ist nicht
die Ursache des Problems.
>> Hast Du vielleicht eine der Dateien "$HOME/.Xmodmap" und "$HOME/.Xkbmap" im
>> HOME-Verzeichnis stehen? Wenn ja, was steht drin?
>
>elirips@XERXES:~$ more .Xmodmap
>keycode 233 = Super_L
Da kann ich auch keine Ursache erkennen.
>> >Zu Shift+ScrLk (sollte NumLk aktivieren/deaktivieren):
>>
>> Meines Wissens kann das nicht funktionieren. Man kann nicht zwei
>> Modifier-Funktionen (hier: »Scroll_Lock« und »Num_Lock«) auf der selben
>> Taste haben, auch nicht, wenn eine von beiden mit und die andere ohne
>> »Shift« betätigt werden soll. Der Grund dafür ist, dass dafür eine
>> Zuordnung zu einem der Modifiers (siehe die erste Spalte der Ausgabe von
>> »xmodmap -pm«) bestehen muss. Die Zuordnung hängt aber nicht am
>> Keysymbol »Scroll_Lock« bzw. »Num_Lock«, sondern am Keycode (hier: 77,
>> siehe die Ausgabe von »xev«). Und das gibt es pro Taste immer nur
>> einmal. Ob dazu »Shift« gedrückt wird oder nicht, ändert am keycode
>> nichts. In der Ausgabe von »xmodmap -pm« findet sich das Keycode
>> jeweils in Klammern als Sedezimalzahl, hier also 77 = 0x4d.
>
>Unter Win funktioniert es. :(
»Win« bedeutet MS-Windows? Das kann gut sein. Dass Modifiers am Keycode
hängen, liegt an X11, nicht an der Tastatur.
>Soweit ich sehe scheint NumLock hier auch 77 zu sein. Drücke ich ScrlLk
>alleine gibt es den Code 78, drücke ich shift+ScrlLk erhalte ich 77. =>
Dass ich es richtig verstehe: Scroll-Lock und Num-Lock liegen auf
derselben Taste; und diese Taste liefert, wenn man sie alleine drückt,
das keycode 78 und das keysymbol »Scroll_Lock«. Hält man jedoch dabei
eine Shift-Taste gedrückt, liefert sie das keycode 77 (statt 78!) und das
keysymbol »Pointer_EnableKeys«.
Dass sich das keycode ändert, ist bemerkenswert, denn das geht über das
traditionelle Verhalten von X11, bei dem keycodes gleich bleiben und sich
nur keysymbols ändern, hinaus. Ich kenne mich da nicht aus. Ich vermute
aber, dass das andere keycode (77 statt 78) bereits von der
Tastatur-Hardware oder wenigstens von einer Ebene unterhalb des
X11-Window-Systems geliefert wird. Das bedeutet dann, dass X11 denkt,
Scroll_Lock und Num_Lock seien zwei verschiedene Tasten.
Weiter geschieht dann Folgendes, wenn man die Shift-Taste drückt und
gedrückt hält und dann dazu die Scroll_Lock-Taste drückt:
X11 erkennt, dass die Shift-Taste gedrückt und gehalten wird, und merkt
sich das, d.h. es merkt sich den Zustand »eine Shift-Taste wird gedrückt
gehalten«. Jetzt wird die Scroll_Lock-Taste (mit keycode 78) gedrückt.
Dadurch, dass das Laptop aus der Kombination der Scroll_Lock-Taste und
der Shift-Taste -- ohne dass X11 etwas davon merkt -- sozusagen heimlich
eine Num_Lock-Taste (mit eigenem keycode!) aus dem Ärmel schüttelt, meint
X11 bei gedrückter Shift-Taste jetzt eine Num_Lock-Taste (mit eigenem
keycode: 77) zu sehen. Weiterhin kennt X11 die Shift-Taste X11 noch als
gedrückt. »xev« zeigt es im »state« an der Einerstelle an:
>> >KeyPress event, serial 29, synthetic NO, window 0x3800001,
>> > root 0x4d, subw 0x0, time 2476371358, (914,10), root:(921,83),
>> > state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
>> > XLookupString gives 0 bytes:
>> > XmbLookupString gives 0 bytes:
>> > XFilterEvent returns: False
>> >
>> >KeyPress event, serial 29, synthetic NO, window 0x3800001,
>> > root 0x4d, subw 0x0, time 2476372021, (914,10), root:(921,83),
>> > state 0x11, keycode 77 (keysym 0xfef9, Pointer_EnableKeys),
^ ^
| Hier sieht man: neues keycode:
| 77 statt 78
|
Hier sieht man: Shift ist aktiv.
Und da liegt dann auch der Hase im Pfeffer:
Weil Deine Tastatur so konfiguriert ist:
keycode 77 = Num_Lock Pointer_EnableKeys
^ ^
| zweites keycode: gilt im Shift-Zustand
|
erstes keycode: gilt ohne Shift-Zustand
erhältst Du, wann immer X11 das keycode 77 sieht, automatisch das
keysymbol »Pointer_EnableKeys« statt »Num_Lock«, denn keycode 77 liefert
die Tastatur nur, wenn gleichzeitig zuvor die Shift-Taste gedrückt worden
ist und noch gedrückt gehalten wird: Der Modifier »shift« ist aktiv.
»Num_Lock« ist also für X11 nicht mehr erreichbar. Dazu passt das
folgende von Dir beobachtete Verhalten:
>Drücke ich erneute shift+ScrlLk gibt es wie gewünscht wieder keycode 77,
>nur wird NumLock nicht wieder abgestellt.
>> >KeyPress event, serial 29, synthetic NO, window 0x3800001,
>> > root 0x4d, subw 0x0, time 2476371358, (914,10), root:(921,83),
>> > state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
>> > XLookupString gives 0 bytes:
>> > XmbLookupString gives 0 bytes:
>> > XFilterEvent returns: False
>> >
>> >KeyPress event, serial 29, synthetic NO, window 0x3800001,
>> > root 0x4d, subw 0x0, time 2476372021, (914,10), root:(921,83),
>> > state 0x11, keycode 77 (keysym 0xfef9, Pointer_EnableKeys),
Probier mal, folgendes Kommando laufen zu lassen:
$ xmodmap -e 'keycode 77 = Num_Lock'
Was zeigt
$ xmodmap -pke | grep -E -e '_Lock|[[:blank:]]Shift|Pointer'
jetzt an? Ist »Pointer_EnableKeys« jetzt verschwunden, d.h. sieht die
Ausgabe dann so wie beim neu angelegten Benutzer (s.u.) aus? Lässt sich
Num_Lock jetzt abschalten?
Wenn Du die Tastaturmaus nutzen willst, brauchst Du allerdings auch
»Pointer_EnableKeys«. Ein Vorschlag wäre, es auf die Caps_Lock-Taste
(mit Shift) zu legen (denn vermutlich braucht man Shift-Caps_Lock sonst
nie zu drücken, das wäre also noch frei):
$ xmodmap -e 'keysym Caps_Lock = Caps_Lock Pointer_EnableKeys'
Damit schaltet dann Shift-Caps_Lock die Tastaturmaus ein oder aus.
>CapsLock gibt keycode 66, also versteh ich nicht ganz weshalb dort auch
>Num Lock aktiviert wird.
Das ist mir auch noch ein Rätsel. Tritt das bei dem neu angelegten
Benutzer (s.u.) auch auf?
>> Was zeigt das Kommando
>>
>> $ xmodmap -pke | grep -E -e '_Lock|[[:blank:]]Shift|Pointer'
>
>elirips@XERXES:~$ xmodmap -pke | grep -E -e '_Lock|[[:blank:]]Shift|
>Pointer'
>keycode 50 = Shift_L
>keycode 62 = Shift_R
>keycode 66 = Caps_Lock
>keycode 77 = Num_Lock Pointer_EnableKeys
>keycode 78 = Scroll_Lock
>
>JA :) Das ist Es. ^^^ verdächtig. Ich habe probehalber mal einen neuen
>User angelegt => Problem tritt *nicht* auf. Dort ist es wie es sein
>sollte:
>
>keycode 50 = Shift_L
>keycode 62 = Shift_R
>keycode 66 = Caps_Lock
>keycode 77 = Num_Lock
>keycode 78 = Scroll_Lock
>
>Also scheint es als ob bei mir irgendwo Müll rumliegt der X/Gnome
>verwirrt. Dann beginn ich mal zu suchen an was das liegen könnte. Ist
>eine relativ alte Installation, zuerst Sarge, dann Etch als Etch testing
>war, und jetzt Etch stable.
Mit Gnome kenne ich mich nun überhaupt nicht aus. Aber vielleicht könnte
es sein, dass Gnome beim Beenden die Tastaturkonfiguration abspeichert?
Dann könnte man hoffen, dass das (einmalige) Entfernen von
»Pointer_EnableKeys« (s.o.) das Problem dauerhaft aus der Welt geschafft
hat.
--
Wer mir E-Mail schreiben will, stelle | When writing me e-mail, please
bitte vor meine E-Mail-Adresse meinen | precede my e-mail address with
Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <xxx@example.net>, (Helmut Waitzmann) xxx@example.net
Reply to: