#483 closed defect (worksforme)
is_native_keymap test is wrong
Reported by: | Antoine Martin | Owned by: | alas |
---|---|---|---|
Priority: | major | Milestone: | 0.12 |
Component: | server | Version: | |
Keywords: | Cc: | mc5686@… |
Description
It is just a little bit too late to get this in version 0.11 (though it could get backported if the fix is simple enough and does not cause any regression)
It looks like the value for is_native_keymap
can end up being True
even on client platforms that do not have native X11 keymap support. This shortcuts a number of codepaths which will need re-testing:
set_keymap
setting themodifiers_filter
to ignorelock
and the modifier forNum_Lock
- do we still need this?get_keycode
uses a more strict key lookup, which may cause some unusual foreign keys not to be looked up?
Change History (9)
comment:1 Changed 8 years ago by
Owner: | changed from Antoine Martin to Antoine Martin |
---|---|
Status: | new → assigned |
comment:2 Changed 8 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
comment:3 Changed 8 years ago by
comment:4 Changed 8 years ago by
I'm not sure this is working properly, I had problems today with "|" with a Linux client, and numbers on a win32 vbox client..
comment:5 Changed 8 years ago by
Testing with windows native r5319 I can't find any keyboard function key not behaving as expected. With osx I even noticed that the clear
button of the numpad behaves like a numlock, allowing the osx numpad to be used as arrow, etc. keys (for anyone who likes that sort of thing).
The numbers on the numpad and keyboard itself are behaving as expected. The "|" key is interpreted correctly in xterms.
I can't think of any other modifier keys to test.
comment:6 Changed 8 years ago by
I am unsure if this applies to this bug (otherwise I will open a new one):
I have an Italian keyboard.
Some keys (notably ',?', '{', '}', '#' and '@') are only available via 'Alt_Gr' escape.
All these keys do not appear to work.
Setup:
- Server:
- Linux Wheezy_amd64
- LANG=en_US.UTF-8
- Client:
- Windows Seven x64
- Italian setup
- Test program:
- eclipse 3.8.0 (installed via apt-get).
- xterm (behaves slightly differently: does not completely ignore Alt_Gr chars, but, for some(e.g.: '['), it beeps indicating some "wrong" input).
- Winswitch was installed today on both machines following indication on web site.
- Both machines are real (no Virtual Macines) installed recently with fairly standard options.
- All software installed is standard and up-to-date.
- All other keys are correctly interpreted as Italian KBD in spite of client/server language mismatch (e.g.: all accented letters are correct).
comment:7 Changed 8 years ago by
Cc: | mc5686@… added |
---|
comment:6 is not specifying on which version the problem is occurring so I assume it isn't trunk, and it isn't related to this ticket, which is about changes present in v0.12 only.
@MCondarelli: please provide more details as per wiki/ReportingBugs and in particular wiki/Keyboard, and if appropriate, place those in a new ticket.
afarr: a bit of testing with Fedora 20 wouldn't hurt, but I haven't had the problem since, maybe it was just a glitch.
comment:8 Changed 8 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Not heard back, assuming this works OK. (see also #561)
comment:9 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/483
I've ripped out the whole code because it seemed bogus: see r5303. I've kept the
is_native_keymap
flag, which is still shown inxpra info
but no longer used.Please test thoroughly to make sure this does not cause keyboard regressions with modifiers (
Alt
,Shift
, etc).