AllowEmptyInput and HAL

Phil Endecott spam_from_xorg at chezphil.org
Thu May 7 03:50:40 PDT 2009


Peter Hutterer wrote:
> On Wed, May 06, 2009 at 10:32:53PM +0100, Phil Endecott wrote:

>> (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',

>> This is when I press 'a'.  Note that mods.mask is 1; it should surely 
>> be 0.
>
> actions are things to be triggered when the matching key combo has been
> pressed. the action you're looking at is to be triggered when shift is
> down, but it does not describe the current state of the keyboard.
>
> the current state is in dev->key->xkbInfo->desc->state, and the current
> modifiers are a binary OR of the base/latched/locked_mods in that state
> field.

Hi Peter,

(gdb) break XkbHandleActions
Breakpoint 1 at 0x8122487: file xkbActions.c, line 1072.
(gdb) cont
Continuing.

Breakpoint 1, XkbHandleActions (dev=0x82bf838, kbd=0x82bf838, 
event=0x82c8268) at xkbActions.c:1072
1072	{
(gdb) print dev->key->xkbInfo->desc->state
There is no member named state.

Maybe this is what you meant:

(gdb) print dev->key->xkbInfo.state
$4 = {group = 0 '\0', base_group = 0, latched_group = 0, locked_group = 
0 '\0', mods = 0 '\0', base_mods = 0 '\0', latched_mods = 0 '\0', 
locked_mods = 0 '\0',
   compat_state = 0 '\0', grab_mods = 0 '\0', compat_grab_mods = 0 '\0', 
lookup_mods = 0 '\0', compat_lookup_mods = 0 '\0', ptr_buttons = 0}

Here initially mods=0, but it changes:

(gdb) cont
Continuing.

Breakpoint 1, XkbHandleActions (dev=0x82bf838, kbd=0x82bf838, 
event=0x82c8268) at xkbActions.c:1072
1072	{
(gdb) print dev->key->xkbInfo.state
$7 = {group = 0 '\0', base_group = 0, latched_group = 0, locked_group = 
0 '\0', mods = 5 '\005', base_mods = 5 '\005', latched_mods = 0 '\0', 
locked_mods = 5 '\005',
   compat_state = 5 '\005', grab_mods = 5 '\005', compat_grab_mods = 5 
'\005', lookup_mods = 5 '\005', compat_lookup_mods = 5 '\005', 
ptr_buttons = 0}

I see a pattern of mods=0 and mods=5 that's consistent with the 
alternating pattern that I posted in the xev output previously.

I am wondering what I could have done to provoke this.  I had a 
~/.xmodmap that maps caps-lock to ctrl, but that is now disabled and I 
was getting the same problem at the xdm login dialog and when root ran 
startx.  I also had changes to the console keymap stuff to get the same 
effect, but I don't believe that the console keymap affects X (hence my 
question before about where X gets the keymap from in a HAL 
environment, i.e. does it somehow use the kernel keymap), and anyway 
that console keymap hack stopped working after the same apt-get that 
broke X.

And I'm still getting errors from xkbcomp, despite disabling my ~/.xmodmap.


Phil.






More information about the xorg mailing list