Re: fn key on lombard (and up) powerbooks...

[Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de>]

> > So we need to do the same for the keyboard device as for the
> > trackpad: store it's device state before sleep. We just need a way
> > to locate it :-)
> 
> Right...the fnset code uses a type value (this doesn't seem to be the
> same as the handler value as seen in the kernel messages).  It's just
> the second byte of the keyboard adb registers:
> 
> here's the output of fnset with -d:
> 
> === reading all registers for device 2. ===
> writing 2 bytes: { 0x00 0x2c }
> read 0 bytes
> writing 2 bytes: { 0x00 0x2d }
> read 3 bytes: { 0x2d 0x04 0x01 }
>                      ^^^^
> 
> writing 2 bytes: { 0x00 0x2e }
> read 3 bytes: { 0x2e 0xff 0xff }
> writing 2 bytes: { 0x00 0x2f }
> read 3 bytes: { 0x2f 0x62 0xc3 }
> === done reading all registers for device 2. ===

=== reading all registers for device 2. ===
writing 2 bytes: { 0x00 0x2c }
read 0 bytes
writing 2 bytes: { 0x00 0x2d }
read 3 bytes: { 0x2d 0x01 0x00 }
writing 2 bytes: { 0x00 0x2e }
read 3 bytes: { 0x2e 0xff 0xff }
writing 2 bytes: { 0x00 0x2f }
read 3 bytes: { 0x2f 0x62 0xc3 }

Apparently, mine's different (why?). We can ignore the register 0 and 2
results, (register 0 would report keycodes, register 2 would hold modifier
key states and LED states - here's the long sought after capslock bit!).
Register 1 has device specific settings, that's what gets used by fnset to
tweak the function key behavior. Register 3 is used to set the handler ID
and for address conflict resolution on bus probe.

What's common is the 0xc3 in register 3 byte 3: That's what the kernel
driver reports as default handler ID (the lower half of byte 2 is the
default address). And the 'handler 1' reported by the kernel is just plain
bogus:

                if (adb_try_handler_change(id, 3))
        		printk("ADB keyboard at %d, handler set to 3\n", id);
                else 
                        printk("ADB keyboard at %d, handler 1\n", id);

The device didn't honor the 'please set yourself to handler 3' request so
it remains at whatever handler ID we had before. This piece of code
doesn't actually know which one that is (would need to call adb_get_infos
for that). Confusing. 

Now whatever is in byte 2 of register 1 has nothing to do with the handler
ID, apparently. To further confuse us, Apple seems to have used such
handler IDs as 1, 2, 4 both for keyboards and mice so we cannot rely on
this for telling keyboards from other stuff. 
Whatever 'address' we read from register 3 byte 2 should be random (the
keyboard being the exception to this rule) so we cannot use that either.
The default address info would tell us if it's a keyboard, but this
information is only known to the kernel so we cannot use it.
The register 1 contents only makes sense once we know the device type. Am
I missing something here? How about adding ioctls to /dev/adb so we can
get the default ID, current and default handler IDs? 

I'd like to see a fnset tool that works with all sorts of Powerbook
keyboards out there before I consider putting anything beyond 'restore the
register 1 and the handler ID for the device at address 2' into pmud. That
seems the least horrible assumption (at least one keyboard will be at 
address 2 currently).

> I believe this is just a sanity check to skip over other keyboards,
> and presumably other keyboards have a different value in this
> location... *shrug* (I /really/ don't know)

Such as mine - I remember now just why I hate ADB so much. 

	Michael