support dual keyboard setups with differing layouts

[totaam]

Issue migrated from trac ticket # 86

component: client | priority: minor | resolution: worksforme

2012-03-08 17:21:02: sergio created the issue

---

Hi,

I have an issue that is probably rare and triggered by a weird system configuration.

This, running an ubuntu linux laptop and using xpra to access an ubuntu linux desktop with an almost identical configuration.

My laptop has an Italian keyboard. When I use xpra with the laptop alone, everything is fine. The Italian keyboard works ok.

Whenever I can, I use the laptop with an external big monitor and an external usb keyboard and mouse, for extra comfort. Since I dislike the Italian keyboard design (it misses many important keys), my external keyboard is US. Here my problems start.

When I connect to the remote machine, the keyboard is initially set to the Italian layout. This is no surprise, nomachine does the same. However, if I try to change the keyboard layout with setxkbdmap -layout us (which works perfectly with nomachine), under xpra the keyboard goes crazy: some keys becomes mute, other take weird settings...

Any advice?

[totaam]

2012-03-11 07:37:23: antoine changed status from new to accepted

[totaam]

2012-03-11 07:37:23: antoine commented

---

Hmm, do you run the "setxkbmap -layout us" on the client or in the xpra session?
You should not modify the keyboard settings of the xpra session, this is meant to be done automatically on startup and everytime you change the client's keyboard configuration, you will see messages like these in the server log:

setting key repeat rate from client: 500 / 30
['setxkbmap', '-rules', 'base', '-model', 'pc105', '-layout', 'gb']
['xkbcomp', '-', ':8'] with stdin=xkb_keymap {\n	xkb_keycodes  { ..

Can you also specify which ubuntu version you are running?
However, your configuration is unusual and it is quite possible that xpra does the wrong thing here - which I will try to fix if I can reproduce it.

[totaam]

2012-03-11 12:06:20: sergio commented

---

Hi,

I am working on kubuntu oneiric. This is what I do:

1. ssh to the remote machine

localmachine> ssh remotemachine

2. start xpra there

remotemachine> xpra start :100

3. attach xpra on the local machine

localmachine> xpra attach ssh:remotemachine:100

4. start a terminal emulator on the remote machine redirecting it via xpra. I use konsole since I am on kde, but xterm would be the same

remotemachine> DISPLAY=:100 konsole

see the remote konsole appearing on the localmachine. Here, I can check that $DISPLAY is set to :100, so any command I issue here implying graphical output via X runs on the remotemachine, but appears on the local machine.

Now, if I type on this terminal emulator, I see that /here/ the keyboard encoding is the Italian one. Remember that on the local machine I have two keyboards, the keyboard inside the laptop (Italian) and the USB keyboard (US). If I type on the laptop keyboard, the characters come out correctly, while if I type on the external one, the characters are mismatched with the keys. This happens in spite of the fact that /the local machine has its keyboard set to US/. That is, if I use a local terminal emulator on the local machine, the characters come out correctly from the USB keyboard and mismatched from the laptop keyboard.

This may already look weird, but is actually what other programs similar to
xpra do. For instance nxclient (nomachine) does the same.

At this point, I try to do what I used to do with nxclient, that is running in the remote terminal emulator

remotemachineterminalemulator> setxkbdmap -layout US -variant euro

With nxclient, this is enough to fix everything. In xpra this does not work. Weird enough, it leaves the keyboard in a strange, mixed state, where the keyboard is not Italian (no more accents), not US (some keys are completely mute).

Note. If I change the local machine keyboard configuration via the keyboard applet, I do not see any further message on the remote machine xpra log. Here I only find the /initial/ keyboard setup:

['setxkbmap', '-rules', 'evdev', '-model', 'pc101', '-layout', 'it,us']
['setxkbmap', '-option', '', '-option', 'compose:rwin']
['xkbcomp', '-', ':100'] with stdin=xkb_keymap {\n      xkb_keycodes  { ..

Note the it,us layout here...

Sergio

PS: Thanks for looking into this in spite of my issue being so unusual

[totaam]

2012-04-17 07:57:44: ahuillet commented

---

I confirm the observation: altering the keyboard layout in the Xpra session, in any way, wrecks it beyond repair. But it seems to be rather expected.

[totaam]

2012-04-18 09:27:02: antoine commented

---

Tricky one that, we ought to be able to make it work with both keyboards.. will need to look into that.

On the other hand, modifying the keymap on the server is a big no-no, but maybe we should detect the changes and override them by re-applying the correct keymap?

[totaam]

2012-04-18 10:02:45: sergio commented

---

Hi, I assume that by 'the server' you mean the machine running xpra start (namely the xpra proxy server) and the X clients to be displayed, not the machine where the X server that is ultimately responsible for the visualization runs.

Unfortunately, to change the keymap on the server is what everybody (or at least me) has learned to do with nx. Hence, my initial reporting of this evidently wrong practice. Obviously, the system should be capable to see what is up on the client and use that.

To begin with, a first step could be to at least see what keymap the client is using when xpra is activated on it. E.g I have 2 keyboards on a client, IT and US. When I start the client I am on the US one even if the 'primary' keyboard is the IT one. Xpra should configure things accordlingly to my setup and not to the 'primary' keyboard. To have xpra dynamically detect and track keyboard re-configurations on the client would of course be even better, but the first step would be more than acceptable in the short time.

Thanks for looking into this!!!

Sergio

[totaam]

2012-05-04 11:00:42: antoine

[totaam]

2012-06-22 11:20:34: antoine commented

---

To make this work, I believe we will need to define 2 keyboards in X11.

First problem is that gtk only reports one keymap, so we will need to bypass it and use direct X11 calls.
Then we also need the new Xkb api (see #149) to define those 2 keyboards.

[totaam]

2012-06-22 11:20:34: antoine

[totaam]

2012-06-24 07:19:52: antoine commented

---

Please provide the output of (not from within xpra, just from a regular terminal):

• setxkbmap -print
• setxkbmap -query
• xmodmap -pm
• xmodmap -pke
• xkbprint -label name $DISPLAY - | gv -orientation=seascape -
• keyboard config files (wherever it is that you configure it... /etc/X11/xorg.conf.d? etc)

And an exact diagram of the keyboard layouts in question (from wikipedia?).
How would I configure my desktop to get the same configuration as yours for testing?

[totaam]

2012-06-24 07:19:52: antoine

[totaam]

2012-06-24 07:30:22: antoine changed title from Weird keyboard behavior to support dual keyboard setups with differing layouts

[totaam]

2012-06-25 13:46:41: Sergio Callegari commented

---

Hi,

how should this information be obtained?

1. By sitting in front of the machine?
2. By connecting to the machine via xorg tunnelled via ssh from my laptop with just its own keyboard (IT)?
3. As in 2 but with my laptop with its own keyboard and an US keyboard with the US keyboard set up in the laptop?
4. some combinations of the above?

In case 1 is required, I will not be able to provide it before a few days since the remote machine is ... remote ;-)

[totaam]

2012-06-25 14:28:45: antoine commented

---

This information comes from the X11 server running on the client machine (generally DISPLAY=:0), the one that has 2 keyboard configured.

How you connect (remote or not) is up to you. If the X11 server is already running, you ought to be able to access it via ssh to that machine, just prefix all the commands above with DISPLAY=:THEDISPLAYNUMBER.
Even the xkbprint one ought to work, since the second command will not be getting the DISPLAY override and should get forwarded via ssh X11 display forwarding to your client machine (untested).

[totaam]

2012-06-26 10:30:30: Sergio Callegari commented

---

Hi, here is the output of the commands above. Obtained by connecting to the remote machine with ssh -X. This connecting from a laptop with its own Italian keyboard and an usb US keyboard, with the desktop environment configured for the US layout.

setxkbmap -print

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+it+us(euro):2+inet(evdev)+compose(rwin)"    };
        xkb_geometry  { include "pc(pc101)"     };
};

setxkbmap -query

rules:      evdev
model:      pc101
layout:     it,us
variant:    ,euro
options:    compose:rwin

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 (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x85),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

... To be continued

[totaam]

2012-06-26 10:33:35: Sergio Callegari uploaded file xmodmap_pke.txt (11.0 KiB)

Output of xmodmap -pke

[totaam]

2012-06-26 10:35:28: Sergio Callegari commented

---

xmodmap -pke

This is long. Please find the output as an attachment.

[totaam]

2012-06-26 10:38:24: Sergio Callegari uploaded file xkbprint.pdf (22.1 KiB)

Graphical output of xkbprint

[totaam]

2012-06-26 10:40:01: Sergio Callegari commented

---

xkbprint -label name $DISPLAY

This is graphical. Please find a pdf file attached.

[totaam]

2012-06-26 10:43:39: Sergio Callegari commented

---

xorg.conf files have all the keyboard config commented out, saying that there is autodetection. I guess that this is done with the help from /etc/default/keyboard

XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT="euro"
XKBOPTIONS="lv3:ralt_switch,compose:rwin"

[totaam]

2012-10-07 10:05:06: antoine commented

---

Can you try with trunk and let me know if there are any improvements?

Can you run this sample code to see if gtk detects your keyboard layout changes properly or not: test_keymap_changes.py.
Whenever you change the layout you should see at least one message like this:

keys_changed((<gtk.gdk.KeymapX11 object at 0x1b7aa50 (GdkKeymapX11 at 0x19c5130)>,))

Followed by a dump of the new keyboard data.

It seems that on my system at least, not all layout changes are firing the code above, so I think we will need to go to X11 directly to get notified of such changes..

---

And remember, never try to change the keyboard settings directly in xpra as this will never work.

[totaam]

2012-10-10 06:54:14: antoine

[totaam]

2012-10-10 06:54:14: antoine commented

---

Re-scheduling for when we implement Xkb.

[totaam]

2012-10-10 08:28:34: Sergio Callegari commented

---

Currently away, I'll make the later tests as soon as I am back.

[totaam]

2014-03-05 08:43:58: totaam uploaded file tray-select-layout.patch (9.0 KiB)

allows the user to switch the server-side layout using the system tray "keyboard" sub menu

[totaam]

2014-03-05 08:45:03: totaam changed status from accepted to new

[totaam]

2014-03-05 08:45:03: totaam commented

---

I don't think we should try to second guess the client's X11 configuration, using setxkbmap it on the client ought to be enough to get things working... Xpra should detect the change and pass it on to the server, which will then set the correct keymap.

That said, please try the attached patch which should give you the option of switching the layout from the tray menu. Does it help? I have briefly tried it with foreign layouts, and choosing one of those does seem to change the server-side keycodes... there is hope!

[totaam]

2014-03-05 08:45:18: totaam changed owner from antoine to sergio

[totaam]

2014-03-19 08:35:17: totaam uploaded file expose-server-keymap.patch (1.4 KiB)

expose the server keymap to the client (could be useful in the future)

[totaam]

2014-06-13 05:37:14: totaam commented

---

Some preparatory / cleanup work in r6773, r6774 and r6775.
Finally, r6776 allows you to select the layout from the tray (or "Auto" which is the default).
Note: for this option to be shown, you must have more than one layout defined, ie:

setxkbmap gb,us

(this could be changed in the future)

Does that solve your problem? It should allow you to "fix" xpra when the problem occurs.

[totaam]

2014-08-01 13:57:22: totaam changed status from new to closed

[totaam]

2014-08-01 13:57:22: totaam changed resolution from ** to worksforme

[totaam]

2014-08-01 13:57:22: totaam commented

---

Not heard back, closing. Feel free to re-open.

[totaam]

2014-08-19 04:32:24: totaam

[totaam]

2014-08-19 04:32:24: totaam commented

---

Was done for milestone 0.14