Opened 6 years ago
Last modified 16 months ago
#1172 assigned enhancement
untranslated keyboard
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 5.0 |
Component: | platforms | Version: | trunk |
Keywords: | win32 osx shadow | Cc: |
Description (last modified by )
Follow up from #1099.
We should just pass the raw scancode to the server when we know it will be able to handle it. ie: win32 client with win32 server.
Also, expand r12399 to support more characters - generate the list? (deal non ascii characters too)
Think about better handling for keyboard layout mismatch between client and server, see ticket:1099#comment:10. We could keep multiple translation tables for each layout in use, then use the correct translation for the currently active keyboard layout.
See #1027, #817.
Change History (9)
comment:1 Changed 6 years ago by
Status: | new → assigned |
---|
comment:2 Changed 6 years ago by
Description: | modified (diff) |
---|
comment:4 Changed 6 years ago by
Summary: | win32 and osx shadow servers untranslated keyboard → untranslated keyboard |
---|
Initial support in r13328: I can attach an X11 client to an X11 server with --keyboard-layout=fr --keyboard-raw=yes
and get a 'fr' layout even though my local keymap is set to 'gb'. The raw keycodes are used unmodified by the server.
Still TODO:
- extend this to shadow servers (win32 and osx)
- maybe support X11 server layout changes: re-detect updated settings
- maybe have an "auto" mode for enabling this when both ends are compatible? (ie: win32 shadow server with win32 client, X11 client with X11 server)
- maybe disable or remove the tray menu for cases where it won't be applicable
comment:5 Changed 4 years ago by
Milestone: | 1.0 → 2.5 |
---|
Rather than extending the key packet with yet more data, we could use #1942 (new packet format).
comment:6 Changed 3 years ago by
Milestone: | 2.5 → 4.0 |
---|
comment:7 Changed 2 years ago by
comment:8 Changed 2 years ago by
Milestone: | 4.0 → 5.0 |
---|
comment:9 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1172
See also #1062, #1171.