[PATCH] does ukbd delay break scan codes?

[Maksim Yevmenkin]

Maksim Yevmenkin wrote:

[...]

>>> I still do not know where it comes from,
>>> but what I found so far is,
>>> that the usb keyboard (or ukbd driver)
>>> seems to delay the break codes for
>>> keys with prefix E0 (which may or may not
>>> have anything to do with my problem).
>>>
>>> E.g., I press Keypad-Enter and see
>>>   E0 1C E0
>>>         ^prefix
>>>      ^make code
>>>   ^prefix
>>> and nothing else. As soon as I press
>>> e.g. Enter (any key works) I see
>>>   9C 1C 9C
>>>         ^break code
>>>      ^make code
>>>   ^delayed break code.
>>>
>>> Does anyone have an idea where that
>>> may come from?
>>
>>
>> i see this to on week old -current. if ukbd(4) delays break code then 
>> this might explain state synchronization problem with kbdmux(4). i 
>> guess we should start digging into ukbd(4), starting with 
>> ukbd_interrupt() to see why this happening.
> 
> 
> just by looking at the code, i think, that ukbd_check_char() should also 
> return "true" if ks_buffered_char[0] != 0, i.e. try the following 
> untested patch

i have tested the attached patch. it works for me. with this patch usb
keyboard return

Feb 23 17:30:54 beetle kernel: e0 1c
Feb 23 17:30:54 beetle kernel: e0 9c

when i press "gray enter" key and ps/2 keyboard return

Feb 23 17:31:41 beetle kernel: e0
Feb 23 17:31:41 beetle kernel: 1c
Feb 23 17:31:41 beetle kernel: e0
Feb 23 17:31:41 beetle kernel: 9c

also i tried to freeze my keyboards by pressing ctrl+f1 but i can not 
reproduce it here.

thanks,
max
-------------- next part --------------
--- ukbd.c.orig	Wed Mar 30 00:32:41 2005
+++ ukbd.c	Thu Feb 23 17:18:37 2006
@@ -1145,9 +1145,7 @@
 	state = (ukbd_state_t *)kbd->kb_data;
 	if (!(state->ks_flags & COMPOSE) && (state->ks_composed_char > 0))
 		return TRUE;
-	if (state->ks_inputs > 0)
-		return TRUE;
-	return FALSE;
+	return ukbd_check(kbd);
 }
 
 /* some useful control functions */