#570 closed defect (needinfo)
Cmd key buggy from Mac to Linux
Reported by: | Timothy Basanov | Owned by: | Timothy Basanov |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | platforms | Version: | 0.12.x |
Keywords: | keyboard | Cc: |
Description
Hi, there,
Thanks for the Xpra, it's an awesome product to use.
I have some troubles with setting my keyboard to work when I connect from Mac to my Linux machine.
I want to be able to remap my control and Cmd keys to Control_L and option to Alt_L.
Looks like it's impossible right now.
On mac I use Xpra.dmg from wineswitch and default server for Trusty:
xpra client version 0.12.4 ** Message: pygobject_register_sinkfunc is deprecated (GstObject) ** (Xpra:25450): WARNING **: Trying to register gtype '(null)' as flags when in fact it is of type '(null)' ** (Xpra:25450): WARNING **: Trying to register gtype 'glong' as enum when in fact it is of type 'glong' ** (Xpra:25450): WARNING **: Trying to register gtype '(null)' as flags when in fact it is of type '(null)' ** (Xpra:25450): WARNING **: Trying to register gtype '(null)' as enum when in fact it is of type '(null)' 2014-05-13 12:33:45,549 Unable to load ArrayDatatype accelerator from OpenGL_accelerate 2014-05-13 12:33:45,575 Unable to load converters accelerators (wrapper, arraydatatype) from OpenGL_accelerate 2014-05-13 12:33:45,578 Unable to load arrayhelpers accelerator from OpenGL_accelerate 2014-05-13 12:33:45,834 Unable to load VBO accelerator from OpenGL_accelerate 2014-05-13 12:33:45,893 Unable to load numpy_formathandler accelerator from OpenGL_accelerate 2014-05-13 12:33:45,894 PyOpenGL warning: OpenGL_accelerate module loaded 2014-05-13 12:33:45,951 using default keyboard settings 2014-05-13 12:33:45,956 desktop size is 2560x1600 with 1 screen(s): 2014-05-13 12:33:45,956 'dhcp-172-19-72-138.mtv.corp.google.com' (903x564 mm) 2014-05-13 12:33:45,956 monitor 1 2014-05-13 12:33:46,333 server: Linux Ubuntu 14.04 trusty, Xpra version 0.12.3 (r6075) 2014-05-13 12:33:46,345 Attached to ssh:timothy:100 (press Control-C to detach) 2014-05-13 12:33:46,410 Unable to load nones_formathandler accelerator from OpenGL_accelerate
I'm using Kinese Freestyle 2 for Mac keyboard, if this is important.
Here is output for xev on XQuartz local Mac , Normal X from Mac to Linux, Xpra from Mac to Linux, Xpra from Mac to Linux (no key swap), xpra from Linux to Linux, X local Linux.
OS / key code (keysym) | left control | left option | left command | right command | right option |
---|---|---|---|---|---|
Local Mac XQuarz | 67 (Control_L) | 66 (Alt_L) | 63 (Meta_L) | 71 (Meta_R) | 69 (Alt_R) |
X From Mac to Linux | 67 (Control_L) | 66 (Alt_L) | 63 (Meta_L) | 71 (Meta_R) | 69 (Alt_R) |
Xpra from Mac to Linux | 64 (Alt_L) | 101 (Alt_L) | 37 (Control_L) | 37 (Control_L) | 114 (Alt_R) |
Xpra from Mac to Linux (no key swap) | 37 (Control_L) | 101 (Alt_L) | 64 (Alt_L) | 113 (Alt_R) | 114 (Alt_R) |
xpra from Linux to Linux | 37 (Control_L) | 64 (Alt_L) + 108 KeyRelease? | 133 (Super_L) + 134 KeyRelease? | 134 (Super_R) (only KeyRelease?) | 108 (Alt_R) (only KeyRelease?) |
X local Linux | 37 (Control_L) | 64 (Alt_L) | 133 (Super_L) | 134 (Super_R) | 108 (Alt_R) |
There are several problems here:
1) Xpra from Mac uses code 64 for either control or command, but xpra from linux uses code 64 for option
2) KeyRelease? Events are messed up when xpra connects from Linux
3) Xpra mapping for Mac are significantly different from both ssh -X and local X mappings, which is confusing
Can you help me to grasp how Xpra selects key codes for key presses and how does it maps it into keysyms?
And is this configurable in any way? Could it be that Xpra X server uses its own configuration?
Thank you.
Attachments (2)
Change History (10)
comment:1 Changed 7 years ago by
comment:2 Changed 7 years ago by
Owner: | changed from Antoine Martin to Timothy Basanov |
---|
Debugging keyboard bugs takes a crazy amount of effort, I am not saying this to discourage you, just so that you are aware of the task ahead.
The main problem on my side, apart from the lack of time, is that I use OSX in virtualbox only, and the virtualization already does some keyboard remapping, and the client OS also intercepts certain keys (though that can probably be configured). I guess I could try a USB keyboard pass-through, maybe that would work.
Judging by the amount of debugging information you have provided, you may have already found wiki/Keyboard?
Xpra from Mac uses code 64 for either control or command, but xpra from linux uses code 64 for option
I haven't looked at the details yet, just bear in mind that we map the mac keycodes to the server keymap.. so things can quickly get confusing.
KeyRelease
Events are messed up when xpra connects from Linux
That would be bug and an unusual one, Linux to Linux works pretty well, usually.
Xpra mapping for Mac are significantly different from both ssh -X and local X mappings, which is confusing
Yes, they would be: the xpra client on OSX does not use X11 at all, it is a native application and therefore does not have access to the X11 keyboard information.
Can you help me to grasp how Xpra selects key codes for key presses and how does it maps it into keysyms?
Yes, it's ugly but you should get debug information by running the server or the client with:
xpra -d keyboard
or even:
xpra -d keyboard,verbose
A brief explanation for the macosx case: we set a default keymap on the server then try to map the macosx keyboard definition (the keysyms definitions for each key), minimizing the amount of remapping from client keycodes to server keycodes. (we generate a translation table as we remap keys). When the osx client sends the server a keycode (and modifier state, keysym, etc..), we look up the real keycode (for the actual server keymap in use) and press/unpress it.
And is this configurable in any way?
Unfortunately not, yet.
Changed 7 years ago by
Attachment: | server-start.txt added |
---|
Changed 7 years ago by
Attachment: | client-start.txt added |
---|
comment:3 Changed 7 years ago by
Looks like Xpra key mappings on a Mac is a mystery for me.
I want to make it behave as close to a normal X app as possible, for me Xpra is a drop-in replacement.
I'm totally comfortable with having XQuarz running or running xmodmap once to save configuration for Xpra to read.
I'll try to spend more time to understand how this works.
Meanwhile here are logs for left control key pressed.
Logs on the client:
2014-05-14 14:15:29,792 mask_to_names(<flags 8192 of type GdkModifierType>)=['mod2'] 2014-05-14 14:15:34,127 mask_to_names(<flags 0 of type GdkModifierType>)=['mod2'] 2014-05-14 14:15:34,127 parse_key_event(<gtk.gdk.Event at 0xd0c5530: GDK_KEY_PRESS keyval=Control_L>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': True, 'keyval': 65507, 'keycode': 59}> 2014-05-14 14:15:34,127 handle_key_action(GLClientWindow(1 : GLPixmapBacking(1, (178, 178), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': True, 'keyval': 65507, 'keycode': 59}>) wid=1 2014-05-14 14:15:34,127 swap keys: translating key '<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': True, 'keyval': 65507, 'keycode': 59}>' to (55, 'Alt_L') 2014-05-14 14:15:34,128 send_key_action(1, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Alt_L', 'pressed': True, 'keyval': 65507, 'keycode': 55}>) 2014-05-14 14:15:36,245 mask_to_names swapping control for meta: control for mod1 2014-05-14 14:15:36,245 mask_to_names(<flags GDK_CONTROL_MASK | GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'mod2']
And on the server:
2014-05-14 14:17:21,816 make_keymask_match(('mod1', 'mod2')) current mask: set(['mod2']), wanted: set(['mod1', 'mod2']), ignoring=None/['lock'], keys_pressed={} 2014-05-14 14:17:21,817 keynames(mod1)=set(['Meta_R', 'Alt_R', 'Meta_L', 'Alt_L']), keycodes=[113, 114, 64, 156, 101, 125], nuisance=False 2014-05-14 14:17:21,817 make_keymask_match(add) ('mod1', 'mod2') modifier mod1 using 113, success: True 2014-05-14 14:17:21,818 make_keymask_match(('mod2',)) current mask: set(['mod1', 'mod2']), wanted: set(['mod2']), ignoring=64/['Alt_L'], keys_pressed={} 2014-05-14 14:17:21,818 modifier ignored (ignored keyname=Alt_L) 2014-05-14 14:17:21,818 modifier mod1 ignored (in ignored keynames=set(['Meta_R', 'Alt_R', 'Meta_L', 'Alt_L'])) 2014-05-14 14:17:21,818 handle_key(2,True,Alt_L,65507,64,('mod2',)) keyboard_sync=False 2014-05-14 14:17:21,818 handle keycode pressing 64: key Alt_L 2014-05-14 14:17:21,818 fake_key(64, True) 2014-05-14 14:17:21,819 handle keycode unpressing 64: key Alt_L 2014-05-14 14:17:21,819 fake_key(64, False) 2014-05-14 14:17:23,924 _clear_keys_pressed()
Additionally I've attached logs from server and a client startup. They output Tons of information.
Hope that this can help us to resolve a problem. =)
comment:4 Changed 7 years ago by
I want to make it behave as close to a normal X app as possible
Then you may be better off compiling xpra against the X11 headers as we do on other X11 based platforms (Linux, BSD, ..). The problem is that there are still dozens of special cases for macs sprinkled throughout the code (checks for sys.platform.startswith("darwin")
usually), and decide which ones can be kept and which ones should fall through..
I'm totally comfortable with having XQuarz running or running xmodmap once to save configuration for Xpra to read.
That's assuming that the XQuartz
keyboard configuration is related to the one we get from GTK
. It should be... but the devil is in the details.
I think you may well be interested in reading: ticket:567#comment:12 which is about "swap_keys" and keyboard sync and explains why we unpress the Alt_L
key (just updated earlier today)
comment:6 Changed 7 years ago by
Resolution: | → needinfo |
---|---|
Status: | new → closed |
comment:7 Changed 7 years ago by
That's ok to close this ticket.
I've invested a dozen hours into this issue, no success.
These issues are definitely tricky.
comment:8 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/570
More info: Mac 10.9.2
Inside xpra session on Linux: