AllowEmptyInput and HAL

[Phil Endecott]

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.