On 02/26/2012 07:10 AM, Jason Wessel wrote:
> On 02/17/2012 05:52 PM, Andrei Warkentin wrote:
>> This fixes the following problems:
>> 1) Typematic-repeat of 'enter' gives warning message.
>> 2) Use of 'keypad enter' gives warning message.
>> 3) Lag on the order of seconds between "break" and "make" when
>>    expecting the enter "break" code. Seen under virtualized
>>    environments such as VMware ESX.
>>
>> Explanations:
>> 1) Holding down 'enter' will not set a repeating sequence
>>    of 0x1c(make)-0x9c(make), but a repeating sequence
>>    of make codes, followed by one break code when the key
>>    is released. Thus, it's wrong to expect the break code
>>    after seeing the 'enter' make code.
>> 2) Keypad enter generates different make/break, namely
>>    0xe0 0x1c and 0xe0 0x9c. The 'generic' logic handles
>>    the 0xe0 escape already, but the special 'enter' logic
>>    always expects '0x9c' and not '0xe0 0x9c', so you get
>>    a warning message, again.
>> 3) When expecting the 'enter' break code, the code polls
>>    the status register in a tight loop, like so -
>>    >  while ((inb(KBD_STATUS_REG) & KBD_STAT_OBF) == 0);
>>
>>    However, it really should do something like -
>>    >  while ((inb(KBD_STATUS_REG) & KBD_STAT_OBF) == 0)
>>    >     cpu_relax(); /* pause */
>>
>>    Basically, it's a common optimization to have a fast
>>    path for accessing often accessed and slow changing I/O
>>    in a virtualized environment. The tight spinning in KDB
>>    seems to run against the logic by ESX keyboard virtualization
>>    code to detect when the fast path or the slow path should
>>    be used to satisfy the keyboard status read, leading to
>>    multi-second timeouts before the 'real' status comes through.
>>    Without knowing ESX internals, it's hard to say if this is
>>    an ESX bug or not, but letting the VM be explicitely descheduled
>>    seems to resolve the problem. I've seen something similar with
>>    shared MMIO buffers with VMs on Hyper-V.
>>
>>    Anyway, given (3), (2) and (1), we might as well blow away the
>>    entire special casing for 'enter'. The break codes will already
>>    be handled correctly, and we get rid of the bugs with repeat
>>    enters and keypad enter key. And of course, there is no
>>    need to AND with 0x7f when checking for 'enter', because we'll
>>    never ever get to this code with a break code (checked for much
>>    earlier).
>>
>>    I tried to figure out the history behind the 'enter' key special
>>    casing code, and it seems to have come from whatever the original
>>    KDB patch was. Perhaps someone can chime in.
>>
> 


Andrei, if you agree with the attached patch, I'll put it in the merge queue.  If you find problems we can go another iteration. :-)

Cheers,
Jason.