From 72c029ea37f04007853a0f23d2b6e322a250b7a2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stephan=20A=C3=9Fmus?= Date: Wed, 4 Sep 2013 09:49:36 +0200 Subject: [PATCH] USB HID: Changed/removed wrong comment. * 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. --- .../drivers/input/usb_hid/ProtocolHandler.cpp | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/src/add-ons/kernel/drivers/input/usb_hid/ProtocolHandler.cpp b/src/add-ons/kernel/drivers/input/usb_hid/ProtocolHandler.cpp index 52a8af77c7..305bddebae 100644 --- a/src/add-ons/kernel/drivers/input/usb_hid/ProtocolHandler.cpp +++ b/src/add-ons/kernel/drivers/input/usb_hid/ProtocolHandler.cpp @@ -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();