xpra icon
Bug tracker and wiki

Changes between Initial Version and Version 3 of Ticket #1607


Ignore:
Timestamp:
08/28/17 05:47:43 (2 years ago)
Author:
Antoine Martin
Comment:

In the log I see samples like this one:

process_key_action(['key-action', 1, 'U093E', True, (), 16779582, '\xe0\xa4\xbe', 38, 2]) server keycode=38
filtered_modifiers_set([])=set([])
filtered_modifiers_set([])=set([])
handle_key(1,True,U093E,16779582,38,()) keyboard_sync=True
is_modifier(38) not found
handle keycode pressing 38: key U093E
fake_key(38, True)

So the unicode character U093E is requested and we press keycode 38 for it. Keycode 38 is defined in the xmodmap as:

keycode  38 = a A U0CBE U0C86 NoSymbol NoSymbol U0C85 NoSymbol U093E U0906 U0905 U0972

The string given matches the unicode value:

$ python -c "print('\xe0\xa4\xbe'.decode('utf8'))"
ा

Which is DEVANAGARI VOWEL SIGN AA.

My guess is that we don't map the full keycode because we are limited to just 8 symbols when we use the core API, we would need to switch to xkb: #1049. You can confirm that by attaching the xmodmap -pke from within the xpra session. I assume that the one you attached is from the client?

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1607

    • Property Owner changed from Antoine Martin to chaanakya
  • Ticket #1607 – Description

    initial v3  
    44}}}
    55
    6 On regular X windows, this works fine - I can switch between all 3 layouts without any issues. Within Xpra, however, the keyboard refuses to output anything on the third layout (hin-kagapa). That is, it switches to that layout, but then does not type anything. I'm using revision 16525.
     6On regular X windows, this works fine - I can switch between all 3 layouts without any issues. Within Xpra, however, the keyboard refuses to output anything on the third layout (hin-kagapa). That is, it switches to that layout, but then does not type anything. I'm using revision r16525.