Messages in this thread | | | Date | Mon, 19 Mar 2007 18:44:01 +0800 | From | Li Yu <> | Subject | [RFC] HID bus design overview. |
| |
-------------------------------------- HID bus design overview. --------------------------------------
A. Terms.
The device of an driver: this mean the device that this driver matched.
B. Design.
As we discussed before, The entire HID subsystem is divided into three layers: 1. HID Driver Layer (HIDDL). This layer is composite of all HID drivers, however, these drivers are not equal each other, there are divided into three kinds: 1.1 Fundamental driver. This is the most natural driver for us, they control hardware or other something that can effect hardware directly. In most cases, each of this kind driver is one standard and extendible implementation of HID specification for specific HID transport layer. For example, usbhid.ko for HID/USB or hidp.ko for Bluetooth/HID. This should alway input-able driver, i.e, it is able to allow HIDAL register input device for its device. 1.2 Shadow driver. These driver is created for those buggy/strange/extended HID device which fundamental driver can't handle rightly/completely. this driver does not share HID information with related fundamental driver, but the HID information of their devices is derived from other device of fundamental driver. These may not be input-able driver. The shadow driver does not share the input device with the related fundamental driver, even shadow driver is input-able, it have new input device in such case. 1.3 HIDDEV drvier. In fact, This isn't one public kind of driver. it just is one optionally flag parameter while register driver (also include shadow driver). When turn on this feature, the HIDAL will create one hiddev for each device of driver, so the every such device also have one hiddev buddy. 2. HID Abstract Layer (HIDAL). This layer maintain HID bus, HID driver, HID device, HID hiddev such logical feature, and interact with input subsystem.
3. HID Transport Layer (HIDTL).
This layer may be rather thin. Up to now, we should have two implementation of transport layer, one for USB, one for Bluetooth.
C. Progress.
Status: USB Fundamental driver works for new HID API now. Working: Shadow driver support. TODO: 1. Shadow driver support. 2. Port some drivers to new HID API, includes: 1) All HID ff drivers. 2) iBook/PowerBook special keys driver. 3. Bluetooth fundamental driver. 4. Bluetooth transport layer. 5. Port Other drivers. 6. HIDDEV/USB driver support. 7. HIDDEV/Bluetooth driver support.
I think that post this text earlier is better decision, well, I guess the new controversy about HID may begin ... PS: In my words, the hiddev is same with rawdev, is it right in your words? I cann't acquire the support for this from my corporation, :( So, I must complete this in my spare time, it may take longer time.
Goodluck.
-Li Yu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |