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

Re: switch from ADB to linux keycodes ...



On 30 Aug 2001 23:57:16 -0700, gtgj@pacbell.net wrote:
>         What problems did you experience?  My first attempt was
> similar and I noticed that it would occassionally get into a bad
> state, as if a spurious 0xff keycode has caused the temp state
> variable for the CapsLock key to be "inverted".  The only way to get
> out would be to cause another extra 0xff to be generated.  (One way
> seems to be to go in and out of "xmon".)

Exactly (although I don't know how to use xmon, so I ended up with a
reversed caps-lock (and thus reversed control, as I had it mapped to
control under X)...

>         I've attached a slightly different patch for adbhid.c which
> may be a little more tolerant of spurious 0xff keycodes.  You should
> be able to hit CapsLock again if it gets into a bad state.  (This only
> generates the extra CapsLock press/release events so you still need
> something like "loadkeys" to remap to Control.)  Yeah, it's still a
> hack and we need something better.

I tried using the 0xff keycode first, to no effect. I looked at the
iControl code and saw that the key code used was 127 (0x7f); that
worked. I have a TiBook... Are the keycodes different, or am I missing
something basic about the way adb works and how the bitmasks are being
used in adbhid.c? (I should probably take some more time to understand
the adb system as a whole)

The iControl code has references to flags and flavor. These seem to
provide additional information about "special" events (i.e.,
non-keyboard events, and the additional cap-slock events). Where is the
equivelent information to be found from within adbhid.c? We should be
able to use that the determine if the keycodes are spurious or not...

Thanks for posting your code. It does appear to be more resiliant to
spurious events than mine.

Gregory P. Keeney
Mad Computer Scientist




Reply to: