[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Another installation report -was- (quite long)

curt@gwis.com (Cowboy) wrote:

>>> > The first thing I noticed was that, when I use Ctrl-Alt-Esc to get
>>> > VMware to relinquish keyboard focus, or when I hit various other
>>> > modifier-key combinations, I get one of the following errors on my Hurd
>>> > console:
>>> > 
>>> >   kd_setleds1: unexpected state (1)
>>> >   kd_setleds1: unexpected state (2)
>>> Seems to be a Mach thing. You could check the keyboard translation code.
>>> (the Mach console and keyboard codes are a bit weird, and not complete.)
> This doesn't seem to be unusuall.
> Though I haven't tried ( and don't recomend it ) much the same effect
> should be obtained by simply unplugging the keyboard from a running PC,
> since this is exactly what you're doing under VMWare with the escape sequence.

Except that you can also get it to happen under VMware by (e.g.) hitting
the shift and control keys on both sides of the keyboard all at once.
Does this happen on a real Hurd box? I suspect that it's a timing issue.

Looking at gnumach-1.2/i386/i386at/kd.[ch], it looks like it happens
when the keyboard driver tries to set the keyboard LEDs before the ack
has come back from the last attempt. It seems like there ought to be a
queue of these rather than the existing code which can only handle one
ack sequence at a time. I'd guess that these ack sequences could easily
get in each other's way when you press multiple modifier keys,
especially in the presence of key repeat.

The problem is probably compounded by set_kd_state() in kd.c calling
kd_setleds1() far more often than it needs to: it should only set the
keyboard LEDs if the Num/Caps Lock state has actually changed.

This is based on a fairly quick glance through the keyboard driver,
though, so I may have misunderstood something.

Colin Watson                                           [cjw44@cam.ac.uk]

Reply to: