Xpra: Ticket #86: support dual keyboard setups with differing layouts

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?



Sun, 11 Mar 2012 07:37:22 GMT - Antoine Martin: status changed

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.


Sun, 11 Mar 2012 12:06:19 GMT - sergio:

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


Tue, 17 Apr 2012 06:57:43 GMT - ahuillet:

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.


Wed, 18 Apr 2012 08:27:02 GMT - Antoine Martin:

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?


Wed, 18 Apr 2012 09:02:44 GMT - sergio:

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


Fri, 04 May 2012 10:00:42 GMT - Antoine Martin: milestone changed


Fri, 22 Jun 2012 10:20:34 GMT - Antoine Martin:

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.


Sun, 24 Jun 2012 06:19:51 GMT - Antoine Martin:

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

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?


Sun, 24 Jun 2012 06:30:22 GMT - Antoine Martin: summary changed


Mon, 25 Jun 2012 12:46:40 GMT - Sergio Callegari:

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 ;-)


Mon, 25 Jun 2012 13:28:44 GMT - Antoine Martin:

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).


Tue, 26 Jun 2012 09:30:30 GMT - Sergio Callegari:

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


Tue, 26 Jun 2012 09:33:34 GMT - Sergio Callegari: attachment set

Output of xmodmap -pke


Tue, 26 Jun 2012 09:35:28 GMT - Sergio Callegari:

xmodmap -pke

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


Tue, 26 Jun 2012 09:38:23 GMT - Sergio Callegari: attachment set

Graphical output of xkbprint


Tue, 26 Jun 2012 09:40:01 GMT - Sergio Callegari:

xkbprint -label name $DISPLAY

This is graphical. Please find a pdf file attached.


Tue, 26 Jun 2012 09:43:39 GMT - Sergio Callegari:

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"

Sun, 07 Oct 2012 09:05:06 GMT - Antoine Martin:

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.


Wed, 10 Oct 2012 05:54:14 GMT - Antoine Martin: milestone changed

Re-scheduling for when we implement Xkb.


Wed, 10 Oct 2012 07:28:34 GMT - Sergio Callegari:

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


Wed, 05 Mar 2014 08:43:58 GMT - Antoine Martin: attachment set

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


Wed, 05 Mar 2014 08:45:02 GMT - Antoine Martin: status changed

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!


Wed, 05 Mar 2014 08:45:17 GMT - Antoine Martin: owner changed


Wed, 05 Mar 2014 12:24:15 GMT - onlyjob: cc set


Wed, 19 Mar 2014 08:35:16 GMT - Antoine Martin: attachment set

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


Fri, 13 Jun 2014 04:37:14 GMT - Antoine Martin:

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.


Fri, 01 Aug 2014 12:57:22 GMT - Antoine Martin: status changed; resolution set

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


Tue, 19 Aug 2014 03:32:23 GMT - Antoine Martin: milestone changed

Was done for milestone 0.14


Sat, 23 Jan 2021 04:45:09 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/86