VNC mit Linux Host, Windows Client: "Alt Gr" spinnt! [SOLVED]

Seite 1 von 1 - Forum: Internet & Provider auf overclockers.at

URL: https://www.overclockers.at/internet-provider/vnc-mit-linux-host-windows-client-alt-gr-spinnt-so_236819/page_1 - zur Vollversion wechseln!

GrandAdmiralThrawn schrieb am 20.11.2013 um 13:35

Grüß euch.

Also, der Titel sagt es schon. Ich schaffe es einfach nicht, die für's deutsche Keyboardlayout unerläßliche "AltGr" Taste im Rahmen einer VNC Connection zum Laufen zu bringen. Das ist aber notwendig, weil man sonst keine @, |, [], {} usw. tippen kann. Sowohl am Host direkt als auch auf den Clients direkt funktioniert das.

Ich hatte das Problem schon von Linux auf Linux, obwohl beide Maschinen eine identische Locale und Keymap hatten, hier habe ich xev benutzt um herauszufinden, daß Alt_R (Alt Right) auf Keycode 113 landet. Also einfach ~/.Xmodmap am Linux Host editiert und Keycode 113 geändert, und danach xmodmap ~/.Xmodmap:

keycode 113 = Alt_R NoSymbol Alt_R NoSymbol Alt_R

Das hat Mal funktioniert!

So, aber jetzt komme ich mit VNC von einem Windows Client auf besagten Server, und da löst die Alt Gr Taste leider gleich zwei Events aus, und zwar Control_L und Alt_L, siehe:

Keypress:

Code:

KeyPress event, serial 33, synthetic NO, window 0x2400001,
    root 0xfc, subw 0x2400002, time 3941946185, (46,38), root:(1010,228),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x2400001,
    root 0xfc, subw 0x2400002, time 3941946185, (46,38), root:(1010,228),
    state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

Keyrelease:

Code:

KeyRelease event, serial 33, synthetic NO, window 0x2400001,
    root 0xfc, subw 0x2400002, time 3941946296, (46,38), root:(1010,228),
    state 0xc, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x2400001,
    root 0xfc, subw 0x2400002, time 3941946296, (46,38), root:(1010,228),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Ich dachte, ich könnte das irgendwie mit keysym in der ~/.Xmodmap hinbiegen, um beide Keys auf Alt_R zu mappen wenn gemeinsam gedrückt, aber bisher bin ich erfolglos geblieben. Auch nicht 100% klar ist mir, wie die Modifier als solche identifiziert werden, generell kenne ich mich mit xmodmap einfach ein bissl zu wenig aus. Is ja recht kryptisch.

Google ist VOLL von gleichartigen Berichten, meistens ohne Lösung, und dieses Problem ist ja schon uralt. Habe übrigens auch etliche VNC Clients getestet, keine Unterschiede zu erkennen.

Was ich will ist, daß die Keymaps einfach immer passen, egal ob ich von einem deutschen Windows System, einem deutschen Linux oder englischen Linux komme.. Wobei das allerwichtigste erst einmal ist, es für einen deutschen Windows Client umzusetzen, weil das ist der wichtigste User, und wenn ich dem eine Umgebung präsentiere, in der er ned Mal Pipes verwenden kann, dann.... najo. Unusable.

Zu Hülf?!

Edit: Der VNC Server ist scheints ein TigerVNC, und das auf CentOS 6 Linux.

GrandAdmiralThrawn schrieb am 22.11.2013 um 10:11

Niemand?

Hansmaulwurf schrieb am 22.11.2013 um 10:45

Zitat von GrandAdmiralThrawn
Niemand?

Nachdem ich mich nicht ganz durchblick leider nein.

Allerdings -> Bei mir funzt altgr + sondertasten bei centos6.4 in komibnation mit tigervnc ootb. Kann ich dir irgendwelche config-files sharen die dir helfen können, oder hab ich die Frage falsch verstanden ?

edit:
Falsch verstanden. Bei mir ist das Verhalten von alt_L+CTRL_L = altgr vollkommen ausreichend, also wird er denk ich genau das machen.

mr.nice. schrieb am 22.11.2013 um 10:46

Hast du eine Möglichkeit das gesuchte Event per Software auszulösen?

Die meisten VNC-Clients haben die Möglichkeit per GUI den gewünschten Tastendruck zu emulieren. Den müsstest du dann aufzeichnen und entsprechend einpflegen.

GrandAdmiralThrawn schrieb am 22.11.2013 um 13:57

Wenn ich wüßte wie? Wie gesagt, Windows schickt Control_L + Alt_L an den Linux Host über VNC. Und Ctrl+Alt funktioniert nicht, wird nicht als AltGr interpretiert.

Soweit ich das verstehe, sind Ctrl+Alt und AltGr auf Windows äquivalent, auf Linux aber nicht. Wenn ich AltGr per Software schicke, kommt am Zielsystem auch Control_L+Alt_L an, also 37+64.

Was ich jetzt per xmodmap zusammenbringen müßte wäre es, die Sequenz der Keycodes "37+64" auf "113" zu mappen. Und genau daran beiße ich mir die Zähne aus.

Ich habe auch keinen VNC Client gefunden, dem ich beibringen könnte, gewisse Keycodesequenzen immer auf einen anderen Keycode zu mappen, wenn der User die entsprechende(n) Taste(n) drückt.

Wenn der VNC Client schon aus "37+64" (also Ctrl+Alt) ein "113" (AltGr) zaubern könnte, dann wär alles in Butter. Ich habe jetzt UltraVNC, TightVNC, RealVNC und TigerVNC als Clients probiert, aber keiner scheint mir sowas zu können.

@Hansmaulwurf: Kommst du von einem Windows Client!?

mr.nice. schrieb am 22.11.2013 um 14:03

Hm und das ganze von der anderen Seite anzugehen und das Tastatur Layout von Windows anzupassen ist keine Option?

Da wüsste ich nämlich ein Tool was das kann.
http://msdn.microsoft.com/en-US/goglobal/bb964665.aspx

Hansmaulwurf schrieb am 22.11.2013 um 14:11

Zitat von GrandAdmiralThrawn
@Hansmaulwurf: Kommst du von einem Windows Client!?

Ja, ich hab im Endeffekt fast das gleiche Setup wie du.

Der Windows-Client ist RealVNC. Bei 6.4 wars gar kein Problem, als Layout am Server hab ich latin-de (no deadkeys) eingestellt beim aufsetzten, wenn ich mich über VNC einlogge, seh ich aber English US. (Keyboard Model ist Generic 105-key (intl) PC)

Ich hab allerdings mal ein ähnlich geartetes Problem gehabt, weil irgendwas ist da mit den Keyboards verbugged meiner Meinung nach. Probier mal mit setkeymap herum. Ich hab sowas auf einem (anderen) 6.3er Server mal gehabt, und nachdem ich ein "setkeymap us" gemacht hab, ging es. Seither ist das in der .bashrc, auch wenn ich ehrlich nicht versteh warum..

GrandAdmiralThrawn schrieb am 22.11.2013 um 14:16

Das Clientlayout anzupassen ist keine Option, dann müßte der User ja mit QWERTY arbeiten, das geht gar nicht.

@Hansmaulwurf: Da hol mich der Teufel. "setxkbmap" meintest du sicher, oder? Also geb ich ein "setxkbmap us", und siehe da, es funktioniert! Unfaßbar.

Jetzt würde ich nur zu gerne wissen was da wirklich passiert und warum das so geht... Aber auf jeden Fall schon Mal danke für den rettenden Hinweis!

Hansmaulwurf schrieb am 22.11.2013 um 15:21

Zitat von GrandAdmiralThrawn
@Hansmaulwurf: Da hol mich der Teufel. "setxkbmap" meintest du sicher, oder? Also geb ich ein "setxkbmap us", und siehe da, es funktioniert! Unfaßbar.

Jetzt würde ich nur zu gerne wissen was da wirklich passiert und warum das so geht... Aber auf jeden Fall schon Mal danke für den rettenden Hinweis!

Ich bin nach 2 Tagen draufgekommen. Dazwischen war ich mehrmals knapp dran meinen Monitor aus dem Fenster zu bugsieren

Keinen Plan warum, falls du drauf kommst, lass mich bitte wissen

GrandAdmiralThrawn schrieb am 22.11.2013 um 15:36

Ich bin hier auch schon ein bissl durchgedreht, nur keine Sorge!

Einziger Unterschied, den ich bisher feststellen konnte ist, daß xev nun vermeldet, daß die Keycodes 37+113, also Control_L+Alt_R (!) ankommen, anstatt Control_L+Alt_L. Eigentlich dürfte das auch so nicht unbedingt funktionieren, außer die xmodmap Modifier springen ned an hier und eine andere mir unbekannte Komponente des Systems regelt das..

xmodmap -pm sagt, daß die 8 Modifier Levels wie folgt aussehen:

Code:

shift	Shift_L (0x32), Shift_R (0x3e)
lock		Caps_Lock (0x42)
control	Control_L (0x25), Control_R (0x6d)
mod1		Alt_L (0x40), Meta_L (0x9c)
mod2		Num_Lock (0x4d)
mod3		
mod4		Super_L (0x73), Super_R (0x74), Super_L (0x7f), Hyper_L (0x80)
mod5		Mode_switch (0x8), ISO_Level3_Shift (0x71), ISO_Level3_Shift (0x7c)

Also wenn ich das Recht verstehe, dann erreiche ich das "control" Level, weil Alt_R kein Modifier zugewiesen und Control_L gedrückt ist. Für Keycode 37 (Control_L) gibts in der ~/.Xmodmap allerdings für Stufe 3 (control) der Modifier auch nix. Also kein "Alt_R" zu sehen dort, nur "NoSymbol". Also eigentlich sollte Control_L+Alt_R gar nichts ergeben.

Gibt es irgendwen, der dieses X11 Keyboard Mapping Zeug wirklich kapiert?! Ich komm' mir vor, wie in Minos' Labyrinth..

Ich meine, eigentlich könnt's mir ja wurscht sein, funktioniert ja, aber zu verstehen, wie das wirklich ineinander greift wär schon ned so blöd.

Die setxkbmap Manpage zu lesen macht auch nur Warzen ins Hirn, aber sonst ned viel.

COLOSSUS schrieb am 22.11.2013 um 16:34

Zitat von GrandAdmiralThrawn
Gibt es irgendwen, der dieses X11 Keyboard Mapping Zeug wirklich kapiert?! Ich komm' mir vor, wie in Minos' Labyrinth..

Peter Hutterer. In Australien lebender Oesterreicher, iirc

GrandAdmiralThrawn schrieb am 22.11.2013 um 20:37

Oje, der entwickelt das Zeug... Ich habe fürchterliche Angst vor diesem Menschen, ich glaube ich lauf lieber schnell davon! :eek: :rolleyes: