Phil Endecott wrote: > Phil Endecott wrote: >> Phil Endecott wrote: >>> Phil Endecott wrote: >>>> Daniel Stone wrote: >>>>> Hi, >>>>> >>>>> On Tue, Apr 28, 2009 at 10:01:25PM +0100, Phil Endecott wrote: >>> >>>>>> I have a keyboard >>>>>> where every alternate keystroke produces the right letter and the >>>>>> others produce garbage (maybe top-bit-set characters?). >>>>> >>>>> Cool. Could you please send xev output? >>>> >>>> Unfortunately this is hard as I cannot log in. Presumably there is >>>> some way in which I can bypass xdm and cause X to start running and >>>> then start xev from another machine, or something. I'll investigate. >>> >>> I started x using startx and I can now retype the following xev >>> output. This is for press-release-press-release of the A key. The >>> pattern then repeats and seems to be consistent with other keys: >>> >>> KeyPress event, serial 27, synthetic NO, window 0xa00001, >>> root 0x3e, subw 0, time 7372197, (78,77), root:(699,464), >>> state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, >>> XLookupString gives 1 bytes: (01) "" >>> XmbLookupString gives 1 bytes: (01) "" >>> XFilterEvent returns: False >>> >>> KeyRelease event, serial 27, synthetic NO, window 0xa00001, >>> root 0x3e, subw 0, time 7372293, (78,77), root:(699,464), >>> state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, >>> XLookupString gives 1 bytes: (01) "" >>> >>> KeyPress event, serial 27, synthetic NO, window 0xa00001, >>> root 0x3e, subw 0, time 7372549, (78,77), root:(699,464), >>> state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, >>> XLookupString gives 1 bytes: (61) "a" >>> XmbLookupString gives 1 bytes: (61) "a" >>> XFilterEvent returns: False >>> >>> KeyRelease event, serial 27, synthetic NO, window 0xa00001, >>> root 0x3e, subw 0, time 7372621, (78,77), root:(699,464), >>> state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, >>> XLookupString gives 1 bytes: (01) "" > >> I've also tried to see what's going on using gdb. This isn't easy as >> the executables seem to be stripped. What I can see is that I get only >> the expected call per key up or down event through as far as >> mieqEnqueue(), so there can't be extra ctrl key events injected before >> that point. I then see four calls to ProcessOtherEvent() for one >> up-and-down, which I believe is perhaps due to the "master" and "slave" >> (I haven't tried to understand this). I think I will need to build a >> non-stripped version to get any further in this direction. > > Overnight I built a new not-stripped xserver using khbuild. This > exhibits similar, but not identical, behaviour to the previous system. > Before alternate keystrokes were sent as if ctrl was pressed [actually > ctrl+shift I think; see state=0x5 above]. Now those keystrokes are > sent as if shift is pressed, i.e. I see state=0x1 in the xev output. > > Running under gdb I now see this: > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0xb7c1f8c0 in realloc () from /lib/libc.so.6 > (gdb) where > #0 0xb7c1f8c0 in realloc () from /lib/libc.so.6 > #1 0x080a6e12 in Xrealloc (ptr=0x82c96f0, amount=248) at utils.c:1127 > #2 0x0809b282 in mieqProcessInputEvents () at mieq.c:398 > #3 0x080be0c7 in ProcessInputEvents () at xf86Events.c:172 > #4 0x080960cc in Dispatch () at dispatch.c:358 > #5 0x0806394a in main (argc=5, argv=0xbfd63874, envp=0x0) at main.c:283 > > I guess this means that realloc thinks ptr=0x82c96f0 is not allocated > or already-freed.
I now think this was spurious. On later runs I got the SIGTRAP elsewhere. I think it might be an artifact of the X code changing signal masks and the way gdb does breakpoints. > Perhaps I should now try valgrind. Valgrind had nothing interesting to report. I now think that the problem must be in the keymap: (gdb) where #0 XkbHandleActions (dev=0x82bf838, kbd=0x82bf838, event=0x83097a8) at xkbActions.c:1183 #1 0x08118fc1 in XkbProcessKeyboardEvent (event=0x83097a8, keybd=0x82bf838) at xkbPrKeyEv.c:159 #2 0x08106289 in AccessXFilterPressEvent (event=0x83097a8, keybd=0x82bf838) at xkbAccessX.c:561 #3 0x08119373 in ProcessKeyboardEvent (ev=0x83097a8, keybd=0x82bf838) at xkbPrKeyEv.c:195 #4 0x0809b08d in mieqProcessDeviceEvent (dev=0x82bf838, event=0x83097a8, screen=0x8201650) at mieq.c:367 #5 0x0809b22f in mieqProcessInputEvents () at mieq.c:427 #6 0x080be0c7 in ProcessInputEvents () at xf86Events.c:172 #7 0x080960cc in Dispatch () at dispatch.c:358 #8 0x0806394a in main (argc=5, argv=0xbfb0d634, envp=0x82c1ed0) at main.c:283 (gdb) print event.detail $24 = {button = 38, key = 38} (gdb) print xkbi->desc->server->key_acts[38] $25 = 56 (gdb) print xkbi->desc->server->acts[56] $28 = {any = {type = 3 '\003', data = "\000\001\000\000\001\000"}, mods = {type = 3 '\003', flags = 0 '\0', mask = 1 '\001', real_mods = 0 '\0', vmods = 256}, group = {type = 3 '\003', flags = 0 '\0', group_XXX = 1 '\001'}, iso = {type = 3 '\003', flags = 0 '\0', mask = 1 '\001', real_mods = 0 '\0', group_XXX = 0 '\0', affect = 1 '\001', vmods = 137109200}, ptr = {type = 3 '\003', flags = 0 '\0', x = 256, y = 137109200}, btn = {type = 3 '\003', flags = 0 '\0', count = 1 '\001', button = 0 '\0'}, dflt = { type = 3 '\003', flags = 0 '\0', affect = 1 '\001', valueXXX = 0 '\0'}, screen = {type = 3 '\003', flags = 0 '\0', screenXXX = 1 '\001'}, ctrls = {type = 3 '\003', flags = 0 '\0', ctrls = 256}, msg = { type = 3 '\003', flags = 0 '\0', message = "\001\000\000\001\000"}, redirect = {type = 3 '\003', new_key = 0 '\0', mods_mask = 1 '\001', mods = 0 '\0', vmods_mask = 256, vmods = 137109200}, devbtn = { type = 3 '\003', flags = 0 '\0', count = 1 '\001', button = 0 '\0', device = 0 '\0'}, devval = { type = 3 '\003', device = 0 '\0', v1_what = 1 '\001', v1_ndx = 0 '\0', v1_value = 0 '\0', v2_what = 1 '\001', v2_ndx = 0 '\0', v2_value = 0 '\0'}, type = 3 '\003'} This is when I press 'a'. Note that mods.mask is 1; it should surely be 0. In a HAL environment with no xorg.conf, how does X know what keymap to use? Phil. _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg