On Mon, Jul 18, 2011 at 06:13:40PM -0700, Jason Gerecke wrote: > I've been trying to hunt down the cause of a bug I was made aware of > under Solaris, but also confirmed to exist under Linux with the > linuxwacom 0.8-series drivers. Basically the problem boils down to the > driver associating the correct keysym to the incorrect keycode. This > only happens on a few of the keys. > > For example... If I map Button1 to "core key Down", the driver saves a > keysym of 0xff54. According to keysymdef.h, this is the correct > hexcode. The xmodmap table indicates that this keysym is linked to the > keycode 104, but when the driver does the conversion it actually gets > keycode 116. This keycode is associated with keysym 0xffec, which is > the "Super_R" key. > > Or, putting that (and a few other examples) another way: > > 0xff54 [Down] (104) -> (116) 0xffec [Super_R] > 0xff57 [End] (103) -> (115) 0xffeb [Super_L] > 0xff53 [Right] (102) -> (114) 0x0 [NoSymbol] > 0xff51 [Left] (100) -> (113) 0xffea [Alt_R] > 0xff9a [Prior] (99) -> (81) 0xffb9 [KP_9] > 0xff52 [Up] (98) -> (111) 0xff61 [Print] > 0xff50 [Home] (97) -> (110) 0xff13 [Pause] > > It's almost like an off-by-N error, but the "Prior" -> "KP_9" > conversion throws a wrench in that theory (note though that KP_9 and > KP_Prior share the same keycode). Anyway, my initial thought was that > there xmodmap was being called in a script and changing the mappings, > but I can't find any evidence of that. My next thought turned to the > keyboard settings in xorg.conf, but removing the model and layout > don't seem to have any effect. > > Any ideas?
the Up->Print issue is a mismatch between the evdev keyboard layout and the xfree86 keyboard layout. Up is 111 in the evdev model but 98 in the xfree86 model. This used to be a issue for virtually everyone when we switched to evdev as standard keyboard driver, eventually fixed by adding a new ruleset to xkeyboard-config and forcing that in the server (unless the legacy keyboard driver is used). My guess is that somehow your setup suffers from exactly that issue. Cheers, Peter ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
