On 30 Aug 2001 23:57:16 -0700, [EMAIL PROTECTED] 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
