Hi, On 03/18/2013 09:24 PM, Pete Batard wrote: > On 2013.03.18 10:32, Hans de Goede wrote: >> Hmm, I'm not sure about claiming LIBUSB_CAP_HAS_HID_ACCESS in Linux, I >> would rather not >> actually, as on Linux there is no special hid code. > > This is not what the capability is about. See below. > >> AFAIK the HID code >> on Windows >> allows accessing the device without doing driver swapping. Where as on >> Linux, driver >> swapping is still required. The fact that driver swapping is a lot >> easier on Linux, >> call libusb_detach_kernel_driver to detach usbhid, and the usbfs driver >> will auto load >> on claim-interface, does not change that it is still needed. > > Please understand what the caps are about. > It's about answering the question: "Can libusbx, on its own, provide feature > X". Nothing more. Nothing less.
Ok. > It doesn't matter if Windows does it without having to detach a driver and > Linux requires a call to libusb_detach. Fact is, using libusbx, and libusbx > alone (i.e. without having to perform additional actions outside of the > library) on both the Linux and Windows platforms, libusbx should be able to > communicate with an HID device. > > If we want to go with "but this is a different case because or detach", then > the only thing you'll get is me adding an extra > "LIBUSBX_HAS_HID_ACCESS_WITH_DETACH" cap set to true on Linux, which won't do > our users any good. Actually I was thinking of proposing just that, so yes if we want to advertise HID support on Linux lets do it with such an extra capability. > > What we really want is tell our users whether libusbx has the capabilities to > access and HID device on its own. That we need to invoke 12 libusbx calls > before it can do or none is irrelevant. On Linux, libusbx _can_ access an HID > device. Saying otherwise will be misleading. > > But to elaborate on that last point, please consider this scenario: > We go with your proposal of setting the HID cap to false on Linux. Lo and > behold, in a few months time, we have the following conversation on this > mailing list > "- Hey guys, I had to go overbudget and overdelay with my project for this, > but just so you know, I produced an addon library that can combine libusbx > and hidapi. The reason I did that is that, while I only need basic USB-like > access from HID, HID access wasn't supported by libusbx on Linux, and I have > to deliver a Windows+Linux USB application... > - Huh, you know that libusbx _does_ provide HID access on Linux. You just > need to call libusb_detach to be granted access > - But libusb_has_capability() told me that HID access was not possible on > Linux!!!" > >> To argue HID-access is supported under Linux would mean to argue that it >> is supported under Darwin too. > > Or that it is supported under Windows by the current libusb (libusb, not > libusbx), since all one has to do is replace the HID driver with WinUSB there. > > But as I explained above, the _BIG_ difference is that under Darwin you need > to do something outside of libusbx (and likewise on Windows without native > HID driver support from the backend). On Linux, you don't. If you want to > pretend that differences between endo and exo don't matter, be my guest. I see the difference, which is why at first I leaned to arguing for having a separate cap for Linux as you just suggested. Let me try to explain why, just as there is a huge difference between internal functionality and something only available when doing extra stuff outside of libusbx, there is a huge difference between being able to access a device without detaching the driver, and accessing it with detaching the driver. Lets say we've a keyboard with some extra functionality, ie an lcd display, or whatever. And the functionality is available through custom hid reports on the same hid interface as where the actual keyboard functionality is. Then surely having a tool for the lcd display detaching the driver is a bad idea, since that will mean that the lcd can now be used, but at the cost of loosing the keyboard ... <snip> > Sorry but I think that's going to be super conter-productive for our users. > The capability is for accessing HID devices, period. Trying to get further > than that is only going to confuse our users or worse, as exposed above, lead > them to believe that HID access is not supported when using libusbx on Linux, > which is plain wrong. Claiming that it will just work like it works on Windows is wrong too though, so lets make it 2 different capabilities. Regards, Hans ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
