AllowEmptyInput and HAL
Phil Endecott
spam_from_xorg at chezphil.org
Wed May 6 10:19:13 PDT 2009
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.
Perhaps I should now try valgrind.
Does any of this look familiar to anyone? It is taking me a very long
time to understand this because I have never looked at any of this code before....
Phil.
More information about the xorg
mailing list