Bad keyboard translations and some modifier keys not working in combos

[vival]

I'm experiencing two problems with the keyboard.

My setup:

• server machine: Arch Linux x64, no DE, WM is herbstluftwm, xpra v1.0.3-r15051, xorg server 1.19.2-1
• client machine: Windows 7 x64, xpra v1.0.3-r15051
• server cmd: xpra shadow :0
• client cmd: xpra attach ssh:---:0

Here is a log from using "-d keyboard" where I press all of the problem keys once in the order of "< > | alt+e": attachment/ticket/1465/t-o.log
Here is the output of "xmodmap -pke": attachment/ticket/1465/t--.txt

First problem is that the keys < and | are translated to > key. This problem only happens if I attach a shadow display, not regular xpra display.

Xev output for these three keys are all the same

KeyPress event, serial 35, synthetic NO, window 0x4600001,
    root 0x44f, subw 0x0, time 73765672, (-289,434), root:(994,470),
    state 0x1, keycode 94 (keysym 0x3e, greater), same_screen YES,
    XKeysymToKeycode returns keycode: 60
    XLookupString gives 1 bytes: (3e) ">"
    XmbLookupString gives 1 bytes: (3e) ">"
    XFilterEvent returns: False

Second problem is that some modifier keys show up in xev but don't actually work. This problem happens whether I attach a shadow display or regular xpra display.

Control and shift have no problem. Alt has a problem.

KeyPress event, serial 35, synthetic NO, window 0x4600001,
    root 0x44f, subw 0x0, time 73724840, (-89,410), root:(1194,446),
    state 0x0, keycode 134 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

It shows up in xev but doesn't work in combos, pressing something like Alt+e will act as if I had pressed Alt then e separately. And when I assign a key to a modifier key with xmodmap, which I have to do for the Super key to ensure I don't activate Windows shortcuts, the same thing will happen, shows up in xev, but doesn't work in combos.

[Antoine Martin]

keyboard debug log

[Antoine Martin]

xmodmap -pke

[Antoine Martin]

Can you please include the matching server "-d keyboard" log?

And any other useful information from wiki/Keyboard.

(I have converted the logs to attachments so they don't bitrot)

[vival]

-d keyboard log from client

[vival]

-d keyboard log from server

[vival]

Keymap_info.exe run on client machine

[vival]

keymap.py run inside xpra session

[vival]

setxkbmap -print run inside xpra session

[vival]

setxkbmap -query run inside xpra session

[vival]

xmodmap -pke run inside xpra session

[vival]

xmodmap -pm run inside xpra session

[vival]

Sorry about disappearing, I've uploaded a bunch of files that the keyboard page asks for. I don't have any special input method and the bug is still present with --no-keyboard-sync.

[Antoine Martin]

Not had time to take a look, sorry.
In the meantime, keyboard grabs may help you - see #1195

[Antoine Martin]

See also #1482.

[Antoine Martin]

Sorry for taking so long to look into this.
The problem was limited to this particular combination:

• shadow servers
• keyboard layouts that require AltGr
• ms windows clients

The fix turns out to be trivial, and server-side only: r17563.
You may or may not also need the fixes from ticket:1665#comment:3 (I have not checked this).

For more information on the nasty AltGr workarounds we have to apply on ms windows, see #923 and #1119 (ancient tickets: #7 and #62 - original changesets: r1755, r1756, r1757, r1758, r1759, r1760, r1769, r1770, r1771)

@vival: please close if this works for you.

[Antoine Martin]

A recent regression in the 3.0 series had similar symptoms (this is fixed in 3.0.9

• see #2687, #2648, #2301, #2702..)

For older 3.0 versions, use:

XPRA_SIMULATE_MODIFIERS=0 xpra start ...

[migration script]

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