Thanks for the reply, Kurt. I found
one of the relevant commits. The comment says:
This delta, adds an extra keyboard object to handle those keys that are not part of the main keyboard class. In particular there are separate HID reports for some of the keys, such as Power keys, and multimedia keys.
These reports might be on separate Interface or in cases where the mouse and keyboard are on the same device, the extra reports may be on the Mouse Interface.
So far I have not tried to combine with Keyboard object as might require multiple inheritance which I would like to avoid.
Also I extended the special key mapping table to map several other keys like F1-12, Arrow, Home/end... To special values where the 0x80 bit is set. I used the same values as used for the Arduino Keyboard library. I did not use their defines as they used defines like KEY_F1, which already exists in core, but in core it is the scan code from the keyboard and not the end user value.
I do not understand the reasoning for using different key codes.
I cannot see in the code how the
KeyboardController class manages to get reports from an extra HID. The
KeyboardController::claim_collection() method looks possibly relevant, but it is not clear to me how it works, or how it fits into the grand scheme of things.
***
I did some testing using the
Mouse.ino example.
1. An Apple USB Keyboard, model A1242, from 2008, is not recognised at all. Connecting the keyboard gives no messages.
2. An Apple USB Keyboard, model A1048, from 2005, does not seem to be supported. Connecting the keyboard only gives the following messages:
Code:
23:51:32.898 -> *** Device Hub1 5ac:1003 - connected ***
23:51:32.898 -> manufacturer: Mitsumi Electric
23:51:32.898 -> product: Hub in Apple Extended USB Keyboa
3. An Apple USB Keyboard, model M2452, from 1999, works — partially. The keys on the numpad do not work as expected. Connecting the keyboard and pressing some F-keys gives the following messages:
Code:
23:52:30.749 -> *** Device Hub1 5ac:1001 - connected ***
23:52:30.749 -> manufacturer: Alps Electric
23:52:30.749 -> product: Hub in Apple USB
23:52:30.932 -> *** Device KB1 5ac:202 - connected ***
23:52:30.932 -> manufacturer: Alps Electric
23:52:30.932 -> product: Apple USB Keyboard
23:52:52.242 -> key 'F1' 194 MOD: 0 OEM: 3A LEDS: 0
23:52:52.678 -> key 'F2' 195 MOD: 0 OEM: 3B LEDS: 0
23:52:53.003 -> key 'F3' 196 MOD: 0 OEM: 3C LEDS: 0
23:52:53.371 -> key 'F4' 197 MOD: 0 OEM: 3D LEDS: 0
23:52:54.050 -> key 'F5' 198 MOD: 0 OEM: 3E LEDS: 0
There is no message about an extra HID having been connected. Therefore, it seems to me that the F-key reports must come from the keyboard device, and not from some extra HID. What am I missing?
***
I am a bit concerned seeing comments such as
// TODO: free resources,
// TODO: queue events, perform callback from Task, or
// WIP: special keys. Is this work still in progress? What work remains to be done?
Is there anything that prevents
PR#18 from being merged?