i2p/haiku-beta6
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

USB HID: Changed/removed wrong comment.

Browse Source 
* The HID driver publishes devices for all handlers that claim
   to know how to work with a device. I see how that is good for
   a combo device like keyboard with built-in touch pad or a single
   USB receiver for a keyboard and mouse. But I wonder about devices
   that publish multiple alternative HID configurations. I think
   my Wacom Tablet has a configuration for a regular mouse and the
   configuration for the actual tablet. And the driver should publish
   a device for one, but not the other. I also don't see in the code
   how a specific configuration is made the active one before the
   protocol is used.
This commit is contained in:
Stephan Aßmus
2013-09-04 09:53:07 +02:00
parent 42cb481fe4
commit 72c029ea37
1 changed files with 7 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/add-ons/kernel/drivers/input/usb_hid/ProtocolHandler.cpp
+7 -10
View File
@@ -77,7 +77,6 @@ ProtocolHandler::AddHandlers(HIDDevice &device, ProtocolHandler *&handlerList,
TRACE("root collection holds %lu application collection%s\n",
appCollectionCount, appCollectionCount != 1 ? "s" : "");
handlerCount = 0;
for (uint32 i = 0; i < appCollectionCount; i++) {
HIDCollection *collection = rootCollection->ChildAtFlat(
COLLECTION_APPLICATION, i);
@@ -87,21 +86,19 @@ ProtocolHandler::AddHandlers(HIDDevice &device, ProtocolHandler *&handlerList,
TRACE("collection usage page %u usage id %u\n",
collection->UsagePage(), collection->UsageID());
// NOTE: There isn't currently a mechanism in place that figures out the
// "best" handler for a device. Consider the case of a tablet input
// device: It might advertise itself as regular mouse in one descriptor.
// If the MouseProtocolHandler is given a chance to look at the device
// first, it might be happy with that descriptor and provide the
// protocol handler. That is why the TabletProtocolHandler and
// JostickProtocolHandlers are given a chance first, so they might look
// for more interesting descriptors that unlock the specific device
// functions best.
// NOTE: The driver publishes devices for all added handlers.
// TODO: How does this work if a device is not a compound device
// like a keyboard with built-in touchpad, but allows multiple
// alternative configurations like a tablet that works as either
// regular (relative) mouse, or (absolute) tablet?
KeyboardProtocolHandler::AddHandlers(device, *collection, handlerList);
JoystickProtocolHandler::AddHandlers(device, *collection, handlerList);
TabletProtocolHandler::AddHandlers(device, *collection, handlerList);
MouseProtocolHandler::AddHandlers(device, *collection, handlerList);
}
handlerCount = 0;
ProtocolHandler *handler = handlerList;
while (handler != NULL) {
handler = handler->NextHandler();