AllowEmptyInput and HAL

[Phil Endecott]

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.