Re: [Libusb-devel] [libusb] #89: libusb_claim_interface fails on Mac OS with HID devices

[libusb T. <tr...@li...>]

#89: libusb_claim_interface fails on Mac OS with HID devices
-------------------------+--------------------------------------------------
  Reporter:  northcob    |        Owner:           
      Type:  defect      |       Status:  closed   
 Component:  libusb-1.0  |   Resolution:  duplicate
  Keywords:  darwin hid  |       Blocks:           
Blocked By:              |  
-------------------------+--------------------------------------------------
Changes (by hjelmn):

  * status:  reopened => closed
  * resolution:  => duplicate


Comment:

 Replying to [comment:4 northcob]:
 > It may be compatible, as in it compiles and runs, but a documented
 function fails to work which constitutes a bug.

 I don't see how a documented function has failed to work? The OS has
 claimed the device and there is no way to punt the driver. This is a
 documented limitation in the darwin implementation.

 > This is all very well if one is writing some code to access a specific
 device.  The problem is that libusb still fails the 'does what it says on
 the tin' test.  To quote your overview page "Linux and Darwin (Mac OS X)
 are supported in the latest release. Windows support is present in git as
 of August 2010."  There no caveats about HID devices being a problem.

 The caveat is that libusb can not possibly access interfaces that are
 claimed by a kernel driver if the kernel driver can't be punted. Its just
 the reality of working with hardware from userspace. This is true for any
 number of devices classes: i.e CDC, HUB, HID...

 > The issue here is that because libusb advertises itself as supporting
 all these systems it has been used by the writers of language bindings
 such as pyusb and ruby-usb.  Indeed if you see my original bug description
 it used pyusb.  Googling around, I even found a couple of HID bindings for
 Python both of which use libusb.  Even hidapi can use libusb on Linux, but
 does not pretend that it would work on Windows or Mac OS.

 hidapi can use libusb on Linux but uses the native HID support in OSX and
 Windows. No need to use libusb.

 > When the software does not work as documented it is clearly the fault of
 libusb.  If you fix either the software or the documentation, then it will
 become a feature not a bug.  It is quite simple you cold save a huge
 amount of other people's time by just adding a caveat about HID devices to
 your Wiki front page.
 >
 > Is that really too painful?

 I agree that we should probably make it a little more clear that hid
 devices should not be accessed using libusb.

 > I am afraid I don't have enough understanding of USB to fix this myself,
 but reading Apple's documentation it seems to me that it might be possible
 to have code in the libusb shield kext which prevented the device
 reporting its HID interface.  OTOH this might not be possible on restart
 because Mac hardware builds a device tree during the POST using the
 OpenFirmware stuff.

 No need to use a shield kext. Use hidapi when working with hid devices.
 Use libusb for devices that don't abuse the HID class.

 Anyway, this ticket is a duplicate of #33 and I still do see no reason to
 add IOHID support to libusb.

-- 
Ticket URL: <http://libusb.org/ticket/89#comment:5>
libusb <http://libusb.org/>
C library for writing portable USB drivers in userspace