GNOME Bugzilla – Bug 369884
Keyboard dose not work correctly with Xsun
Last modified: 2006-12-06 10:13:52 UTC
Please describe the problem: Most alphabet keys on keyborad dose not work correctly on Sparc platform Steps to reproduce: 1. Start vino server on a sparc machine 2. connect vino server from a client (java client or vnc viewer) 3. open on terminal 4. try to input something from keyborad Actual results: among the alphabet keys only 'e' works. Others don't work. Expected results: every key on keyboard should work Does this happen every time? yes Other information:
Created attachment 75915 [details] test case for XGetKeyboardMapping
This bug is caused which call XGetKeyboardMapping to get keycode/keysym mapping table. A test case for this api is attached. How to reproduce: 1) compile this XGetKeyboardMapping-test.c. (find how to build in souce code) 2) $./a.out|grep 0x61;./a.out|grep 0x41; Expected result(under Xorg): 0x61 -> 38 0 0x41 -> 38 1 0x61 means 'a', while 0x41 means 'A'. second colomn(38) should be same, third column should be different, uppercase is 1, lowercase is 0. Actual result: 0x41 -> 11 0 Only 'A' is here, and third column should be 1. Most alphabet character is wrong except key 'e'.
Created attachment 75918 [details] test-kbd.c Please attach the output from running this version of the test case on Xsun
Created attachment 75921 [details] Xsun output of test-kbd.c
Okay, this doesn't look like a vino issue to me. It looks like Xsun is returning a broken mapping from XGetKeyboardMapping() If you look through the output, the only alphabetical latin1 keysyms defined (1st column, 0x0041 to 0x005a and 0x0061 to 0x007a) are upper case and don't have any modifier ... the single exception is e/E (0x65/0x45) Definitely looks like an Xsun problem to me.
Mark, on Xsun, the output of XGetKeyboardMapping() is incorrect. But I find a way to initlize the correct mapping table, could you have a look? Another thing is how to get keysyms_per_keycode without call XGetKeyboardMapping()? If have, this patch need to be changed. Index: vino-head/server/vino-input.c =================================================================== RCS file: /cvs/gnome/vino/server/vino-input.c,v retrieving revision 1.5 diff -u -r1.5 vino-input.c --- vino-head/server/vino-input.c 16 Nov 2005 08:18:43 -0000 1.5 +++ vino-head/server/vino-input.c 23 Nov 2006 11:49:31 -0000 @@ -124,10 +124,9 @@ for (modifier = 0; modifier < keysyms_per_keycode; modifier++) { - guint32 keysym = keymap [keycode_index + modifier]; + guint32 keysym = XKeycodeToKeysym (xdisplay, keycode, modifier); - if (VINO_IS_LATIN1_KEYSYM (keysym) && - XKeysymToKeycode (xdisplay, keysym) == keycode) + if (VINO_IS_LATIN1_KEYSYM (keysym)) { if (global_input_data.keycodes [keysym] != 0) continue;
Very strange. Two interesting points about XKeycodeToKeysym() - it uses a cached keyboard mapping ... we're not adding roundtrips by using this function - it has logic along the lines of "there's no keysym associated with keycode 11 and modifier 1, but keycode 11 with no modifier maps to uppercase A, so that means keycode 11 with no modifier gives lowercase a and keycode 11 with modifier 1 gives uppercase A" Truly bizarre, but the logic is clearly meant to match Xsun's weird XGetKeyboardMapping() output, so we should just use XKeycodeToKeysym() I'd be very interested to find out the historical reason for this, though Committed the following to HEAD: 2006-12-06 Mark McLoughlin <mark@skynet.ie> Fix broken keyboard handling on Xsun by making use of Xlib's strange "guess lowercase keysym from upper-case keycode mapping" logic in XKeycodeToKeysym() Based on patch from Halton Huo <halton.huo@sun.com> in bug #369884 * server/vino-input.c: (vino_input_initialize_keycodes): use XKeycodeToKeysym() rather than XGetKeyboardMapping() to build our keysym->keycode mapping.
Created attachment 77801 [details] [review] vino-fix-keymap-xsun.patch