Xpra: Ticket #588: Keyboard mapping issue: numerical keypad

Context:

When the numerical keypad is activated (num lock on) and I press the '.' key then it is printed ';' in the xpra client.

Here are some logs:

windows computer (I pressed the '.' key only once): screenshot.jpg

time).

    KeyPress event, serial 30, synthetic NO, window 0xe00001,
        root 0x44, subw 0x0, time 402278199, (94,80), root:(98,103),
        state 0x0, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
        XLookupString gives 0 bytes:
        XmbLookupString gives 0 bytes:
        XFilterEvent returns: False
    KeyRelease event, serial 30, synthetic NO, window 0xe00001,
        root 0x44, subw 0x0, time 402278199, (94,80), root:(98,103),
        state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
        XLookupString gives 0 bytes:
        XFilterEvent returns: False
    KeyPress event, serial 30, synthetic NO, window 0xe00001,
        root 0x44, subw 0x0, time 402278200, (94,80), root:(98,103),
        state 0x10, keycode 59 (keysym 0x3b, semicolon), same_screen YES,
        XLookupString gives 1 bytes: (3b) ";"
        XmbLookupString gives 1 bytes: (3b) ";"
        XFilterEvent returns: False
    KeyRelease event, serial 30, synthetic NO, window 0xe00001,
        root 0x44, subw 0x0, time 402278201, (94,80), root:(98,103),
        state 0x10, keycode 59 (keysym 0x3b, semicolon), same_screen YES,
        XLookupString gives 1 bytes: (3b) ";"
        XFilterEvent returns: False
    KeyPress event, serial 30, synthetic NO, window 0xe00001,
        root 0x44, subw 0x0, time 402278201, (94,80), root:(98,103),
        state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
        XLookupString gives 0 bytes:
        XmbLookupString gives 0 bytes:
        XFilterEvent returns: False
    KeyRelease event, serial 30, synthetic NO, window 0xe00001,
        root 0x44, subw 0x0, time 402278201, (94,80), root:(98,103),
        state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
        XLookupString gives 0 bytes:
        XFilterEvent returns: False
    KeyPress event, serial 30, synthetic NO, window 0xe00001,
        root 0x44, subw 0x0, time 402278280, (94,80), root:(98,103),
        state 0x0, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
        XLookupString gives 0 bytes:
        XmbLookupString gives 0 bytes:
        XFilterEvent returns: False


Wed, 04 Jun 2014 08:11:57 GMT - capitn: attachment set


Wed, 04 Jun 2014 13:43:49 GMT - Antoine Martin: attachment set

xmodmap -pke output (copy to attachment to make the ticket more readable)


Wed, 04 Jun 2014 13:44:22 GMT - Antoine Martin: attachment set

Keymap_info.exe output (copy to attachment to make the ticket more readable)


Wed, 04 Jun 2014 13:45:03 GMT - Antoine Martin: attachment set

"xpra info | grep keyboard" output (copy to attachment to make the ticket more readable)


Wed, 04 Jun 2014 13:50:02 GMT - Antoine Martin: owner, status, description changed

(edit: replacing large data with attachments)


Wed, 04 Jun 2014 13:51:38 GMT - Antoine Martin: description changed


Wed, 04 Jun 2014 14:30:26 GMT - Antoine Martin:

Well, I've tried to reproduce this by plugging an external keyboard and using USB pass-through with virtualbox then setting mswindows to 'FR' layout, and I just cannot see any of this crazy behaviour where one keypress ends up generating almost a dozen key events. I always get exactly two events (key down, key up).

Are you using vmware or something else that could interfere with the keyboard? It definitely looks like something is messing up with Num_Lock and we get two key-up events for a single key-down... which is very odd.


Thu, 05 Jun 2014 07:55:23 GMT - Antoine Martin:

Confirmed: I think it is safe to ignore the repeated keys and Num_Lock weirdness which are more than likely caused by a virtual machine (KVM) accessed over RDP. Not a problem with GTK or the OS reporting the wrong keys multiple times.


Thu, 05 Jun 2014 09:56:23 GMT - Antoine Martin:

Summary

Summary of the attachments above (parts relating to the key we are interested in) and more:

Note that we also have:

keycode 134 = KP_Decimal KP_Decimal KP_Decimal KP_Decimal KP_Decimal KP_Decimal KP_Decimal KP_Decimal

This is broadly similar to what is found on a plain Linux host (bar 8 entries created instead of just 4.. caused by Xkb vs core api)

So the automatic key mapping has chosen the second option for KP_Decimal.

Two keycodes... and quite different values from the ones we find for Delete:

65535             Delete            46                0                 0
65535             Delete            46                0                 1
65535             Delete            46                1                 0
65535             Delete            46                1                 1

The keycode for Delete is the keyval for KP_Decimal!?



Testing with Fedora 20 Server / Windows XP Client

TIL: the event contains: 'string': '.', 'keyname': 'period', 'pressed': True, 'keyval': 46, 'keycode': 110

TIL: we translate (110, period) to (59, period).


Thu, 05 Jun 2014 11:32:27 GMT - Antoine Martin: attachment set

ugly patch which renames the windows keyboard keyname for the "."


Thu, 05 Jun 2014 11:36:43 GMT - Antoine Martin:

The patch above seems to work for me. Before merging, I would like to find a cleaner way of patching the gtk keymap in the per-platform classes rather than having it completely hardcoded. Then I'll worry about backports.

Does the beta win32 build work for you? (no need to update the server)



For reference, here's the server keymapping phase (edited log summary):

set_keycodes key -1 (set([('KP_Delete', 2), ('KP_Decimal', 1), ('KP_Decimal', 3), ('KP_Delete', 0)])) mapped to keycode=91

Fri, 06 Jun 2014 11:16:15 GMT - Antoine Martin: status changed; resolution set

r6667 is a better fix, but too intrusive to backport.

So I've applied the more ugly workaround in r6669 for the v0.13.x branch, this will be part of 0.13.4


Sun, 08 Jun 2014 06:03:37 GMT - Antoine Martin:

Some related tickets I've found:


Sat, 28 Nov 2015 09:56:27 GMT - Antoine Martin: description changed


Sat, 23 Jan 2021 05:00:11 GMT - migration script:

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