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?
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.
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
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.
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?
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
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.
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 -
/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?
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 ;-)
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).
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
Output of xmodmap -pke
xmodmap -pke
This is long. Please find the output as an attachment.
Graphical output of xkbprint
xkbprint -label name $DISPLAY
This is graphical. Please find a pdf file attached.
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"
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.
Re-scheduling for when we implement Xkb.
Currently away, I'll make the later tests as soon as I am back.
allows the user to switch the server-side layout using the system tray "keyboard" sub menu
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!
expose the server keymap to the client (could be useful in the future)
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.
Not heard back, closing. Feel free to re-open.
Was done for milestone 0.14
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/86