Hi, On 03/17/2013 11:33 PM, Pete Batard wrote: > Last of the patches I wanted to have for the 1.0.15 release. > Unless there are comments, my plan will be to integrate this patch in 24 > hours and declare RC. > > This patch adds a new caps attribute to the backend struct. I preferred to do > it this way because I think it makes sense to have our backend attributes > within the backend struct, especially as we may have to set them at runtime > (in that case, we will have to remove the const qualifiers on our backend > instances, which shouldn't be an issue, but for HID this wasn't necessary). > > Because I don't really want to guess what libusb will do, I introduced > LIBUSB_CAP_HAS_HID_ACCESS at 0x100, which should leave us enough room, and > internally USBI_CAP_HAS_HID_ACCESS defined to 0x10000. The latter is meant to > be used as a bitmask, which oughta simplify our testing for it, while the > former isn't, hence the need for two separate constants. > > You'll also note that I bumped LIBUSBX_API_VERSION on account of > libusb_has_capability() returning nonzero rather than 1 when a capability is > supported. I'm pretty confident that nobody was using > libusb_has_capability(), since we had nothing to test until now, or that if > they did, they probably weren't testing for an explicit value, but since > we're effectively modifying the API, we might as well not take any risks. > > Also, even if as of right now, this isn't actually required, I've updated the > doc for _has_capability() to indicate that it should always performed after > init, so that a backend has a chance to update its caps at runtime. > > Finally, I'm not sure if we want to test for > libusb_has_capability(LIBUSB_CAP_HAS_HID_ACCESS) in xusb. Ideally, we > probably should do that for the HID specific tests, but I'd rather avoid > having to take some time to do just that. Note that I did test that > libusb_has_capability() was working as expected with regards to HID on > Windows and Linux. > > Oh, and just a note on *BSD - I expect the platform to behave the same as > Linux, so I set the HID cap as enabled there, but maybe this isn't correct. > At any rate I'll try to run some *BSD tests on a VM during the RC duration, > but if someone knows something about HID and *BSD, please speak now.
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. 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. To argue HID-access is supported under Linux would mean to argue that it is supported under Darwin too. One can create a code-less kext (a darwin driver) and do a driver swap of the official hid driver with that for a certain hid device, and then access it through libusbx fine on Darwin. So I would like to suggest to document that the capability is for accessing HID devices without detaching the OS native's HID driver, and that HID devices can be accessed on platforms without the capability too as long as the native driver is detached (and where necessary replaced with a generic libusb compatible driver). And then only claim the capability for windows. 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
