LibUSB › LibUSB Dev

OpenUSB / LibUSB on Mac OS X

Classic

List

Threaded

22 messages Options

Michael Lewis

OpenUSB / LibUSB on Mac OS X

I ran across a bug with OpenUSB on Mac OS X 10.7 recently. Basically,
I had two processes trying to keep the device open. I looked through
the code and found this:

/* Try to actually open the device */
#if !defined (OPENUSB_NO_SEIZE_DEVICE)
kresult = (*(hdev->priv->device))->USBDeviceOpenSeize (hdev->priv->device);
#else
/* No Seize in OS X 10.0 (Darwin 1.4) */
kresult = (*(hdev->priv->device))->USBDeviceOpen (hdev->priv->device);
#endif

Is there any reason we can't always just use USBDeviceOpen to prevent
exclusive connections? I thought it might have to do with setting the
configuration, but my testing shows that the device will work just
fine with USBDeviceOpen.

So, if there is a reason not to change it, please let me know and I
won't, otherwise I will probably submit the change in a few days.

--Mike Lewis
"Be who you are and say what you feel, because those who mind don't
matter and those who matter don't mind." --Dr. Seuss

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Peter Stuge

Re: OpenUSB / LibUSB on Mac OS X

Michael Lewis wrote:

FWIW libusb generally does not enforce exclusive connections, leaving
the decision up to the kernel. OpenUSB can of course take a different
approach and that's perfectly fine.

//Peter

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Michael Lewis

Re: OpenUSB / LibUSB on Mac OS X

On Tue, Jan 31, 2012 at 11:46 AM, Peter Stuge <[hidden email]> wrote:

> Michael Lewis wrote:
>> I ran across a bug with OpenUSB on Mac OS X 10.7 recently. Basically,
>> I had two processes trying to keep the device open. I looked through
>> the code and found this:
>>
>> /* Try to actually open the device */
>> #if !defined (OPENUSB_NO_SEIZE_DEVICE)
>> kresult = (*(hdev->priv->device))->USBDeviceOpenSeize (hdev->priv->device);
>> #else
>> /* No Seize in OS X 10.0 (Darwin 1.4) */
>> kresult = (*(hdev->priv->device))->USBDeviceOpen (hdev->priv->device);
>> #endif
>>
>> Is there any reason we can't always just use USBDeviceOpen to prevent
>> exclusive connections? I thought it might have to do with setting the
>> configuration, but my testing shows that the device will work just
>> fine with USBDeviceOpen.
>>
>> So, if there is a reason not to change it, please let me know and I
>> won't, otherwise I will probably submit the change in a few days.
>
> FWIW libusb generally does not enforce exclusive connections, leaving
> the decision up to the kernel. OpenUSB can of course take a different
> approach and that's perfectly fine.

My understanding of the problem is that there are certain operations,
such as setting the configuration, won't work WITHOUT exclusive
access. Currently OpenUSB and libusb-1.0 use the same method to open
the device. I'm not OS X expert, but if we leave things as they are,
is there a way to "seize" the device from another instance in order to
perform operations such as setting the configuration?

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Nathan Hjelm-2

Re: OpenUSB / LibUSB on Mac OS X

In reply to this post by Michael Lewis

USBDeviceOpenSeize is needed to cause the kernel driver to attach from the device (if the driver supports the feature) so I wouldn't change it. You might be able to close after the Seize and reopen immediately with USBDeviceOpen but the kernel driver might reattach.

BTW, why would two processes want to open the same device? Only one process at a time can send control messages to a device at one time on MacOS X.

-Nathan

On Jan 31, 2012, at 5:42 AM, Michael Lewis wrote:

> I ran across a bug with OpenUSB on Mac OS X 10.7 recently. Basically,
> I had two processes trying to keep the device open. I looked through
> the code and found this:
>
> /* Try to actually open the device */
> #if !defined (OPENUSB_NO_SEIZE_DEVICE)
> kresult = (*(hdev->priv->device))->USBDeviceOpenSeize (hdev->priv->device);
> #else
> /* No Seize in OS X 10.0 (Darwin 1.4) */
> kresult = (*(hdev->priv->device))->USBDeviceOpen (hdev->priv->device);
> #endif
>
> Is there any reason we can't always just use USBDeviceOpen to prevent
> exclusive connections? I thought it might have to do with setting the
> configuration, but my testing shows that the device will work just
> fine with USBDeviceOpen.
>
> So, if there is a reason not to change it, please let me know and I
> won't, otherwise I will probably submit the change in a few days.
>
>
> --Mike Lewis
> "Be who you are and say what you feel, because those who mind don't
> matter and those who matter don't mind." --Dr. Seuss
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Michael Lewis

Re: OpenUSB / LibUSB on Mac OS X

On Tue, Jan 31, 2012 at 4:29 PM, Nathan Hjelm <[hidden email]> wrote:
> USBDeviceOpenSeize is needed to cause the kernel driver to attach from the device (if the driver supports the feature) so I wouldn't change it. You might be able to close after the Seize and reopen immediately with USBDeviceOpen but the kernel driver might reattach.
>
> BTW, why would two processes want to open the same device? Only one process at a time can send control messages to a device at one time on MacOS X.

Thanks, I won't change it then. However, in my case I have a scanner
with a TWAIN driver on OS X 10.7 (the previous versions don't do this)
the os loads the TWAIN driver when the device connects and keeps it
open. Then when my regular application tries to connect, it can't
because the device is already exclusively opened. I know, it doesn't
make sense to me either. I believe I can prevent it by not allowing
the os to recognize the device (aka removing the device info from the
TWAIN driver). That seems sleazy, but given what you've just said it
might be my only option.

Thanks for your input.

>
> -Nathan
>
> On Jan 31, 2012, at 5:42 AM, Michael Lewis wrote:
>
>> I ran across a bug with OpenUSB on Mac OS X 10.7 recently. Basically,
>> I had two processes trying to keep the device open. I looked through
>> the code and found this:
>>
>> /* Try to actually open the device */
>> #if !defined (OPENUSB_NO_SEIZE_DEVICE)
>> kresult = (*(hdev->priv->device))->USBDeviceOpenSeize (hdev->priv->device);
>> #else
>> /* No Seize in OS X 10.0 (Darwin 1.4) */
>> kresult = (*(hdev->priv->device))->USBDeviceOpen (hdev->priv->device);
>> #endif
>>
>> Is there any reason we can't always just use USBDeviceOpen to prevent
>> exclusive connections? I thought it might have to do with setting the
>> configuration, but my testing shows that the device will work just
>> fine with USBDeviceOpen.
>>
>> So, if there is a reason not to change it, please let me know and I
>> won't, otherwise I will probably submit the change in a few days.
>>
>>
>> --Mike Lewis
>> "Be who you are and say what you feel, because those who mind don't
>> matter and those who matter don't mind." --Dr. Seuss
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Libusb-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

Vitali Lovich-2

Re: OpenUSB / LibUSB on Mac OS X

Either use the OS imaging APIs that let you access the device from a
higher level or write a codeless kext so that the kernel driver
doesn't grab the device & you can use libusb to write your own
userspace driver.

-Vitali

On Tue, Jan 31, 2012 at 2:43 PM, Michael Lewis <[hidden email]> wrote:

> On Tue, Jan 31, 2012 at 4:29 PM, Nathan Hjelm <[hidden email]> wrote:
>> USBDeviceOpenSeize is needed to cause the kernel driver to attach from the device (if the driver supports the feature) so I wouldn't change it. You might be able to close after the Seize and reopen immediately with USBDeviceOpen but the kernel driver might reattach.
>>
>> BTW, why would two processes want to open the same device? Only one process at a time can send control messages to a device at one time on MacOS X.
>
> Thanks, I won't change it then. However, in my case I have a scanner
> with a TWAIN driver on OS X 10.7 (the previous versions don't do this)
> the os loads the TWAIN driver when the device connects and keeps it
> open. Then when my regular application tries to connect, it can't
> because the device is already exclusively opened. I know, it doesn't
> make sense to me either. I believe I can prevent it by not allowing
> the os to recognize the device (aka removing the device info from the
> TWAIN driver). That seems sleazy, but given what you've just said it
> might be my only option.
>
> Thanks for your input.
>
>
>>
>> -Nathan
>>
>> On Jan 31, 2012, at 5:42 AM, Michael Lewis wrote:
>>
>>> I ran across a bug with OpenUSB on Mac OS X 10.7 recently. Basically,
>>> I had two processes trying to keep the device open. I looked through
>>> the code and found this:
>>>
>>> /* Try to actually open the device */
>>> #if !defined (OPENUSB_NO_SEIZE_DEVICE)
>>> kresult = (*(hdev->priv->device))->USBDeviceOpenSeize (hdev->priv->device);
>>> #else
>>> /* No Seize in OS X 10.0 (Darwin 1.4) */
>>> kresult = (*(hdev->priv->device))->USBDeviceOpen (hdev->priv->device);
>>> #endif
>>>
>>> Is there any reason we can't always just use USBDeviceOpen to prevent
>>> exclusive connections? I thought it might have to do with setting the
>>> configuration, but my testing shows that the device will work just
>>> fine with USBDeviceOpen.
>>>
>>> So, if there is a reason not to change it, please let me know and I
>>> won't, otherwise I will probably submit the change in a few days.
>>>
>>>
>>> --Mike Lewis
>>> "Be who you are and say what you feel, because those who mind don't
>>> matter and those who matter don't mind." --Dr. Seuss
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Libusb-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

Nathan Hjelm-2

Re: OpenUSB / LibUSB on Mac OS X

In reply to this post by Michael Lewis

I meant detach from the device not attach. But yes, if Seize doesn't work then the driver won't let go and you have to write a (now less) codeless kext to claim the device/interfaces.

-Nathan

On Jan 31, 2012, at 3:43 PM, Michael Lewis wrote:

Michael Lewis

Re: OpenUSB / LibUSB on Mac OS X

On Jan 31, 2012 7:14 PM, "Nathan Hjelm" <[hidden email]> wrote:
>
> I meant detach from the device not attach. But yes, if Seize doesn't work then the driver won't let go and you have to write a (now less) codeless kext to claim the device/interfaces.

I was afraid of that, thanks for the help.

>
> On Jan 31, 2012, at 3:43 PM, Michael Lewis wrote:
>
> > On Tue, Jan 31, 2012 at 4:29 PM, Nathan Hjelm <[hidden email]> wrote:
> >> USBDeviceOpenSeize is needed to cause the kernel driver to attach from the device (if the driver supports the feature) so I wouldn't change it. You might be able to close after the Seize and reopen immediately with USBDeviceOpen but the kernel driver might reattach.
> >>
> >> BTW, why would two processes want to open the same device? Only one process at a time can send control messages to a device at one time on MacOS X.
> >
> > Thanks, I won't change it then. However, in my case I have a scanner
> > with a TWAIN driver on OS X 10.7 (the previous versions don't do this)
> > the os loads the TWAIN driver when the device connects and keeps it
> > open. Then when my regular application tries to connect, it can't
> > because the device is already exclusively opened. I know, it doesn't
> > make sense to me either. I believe I can prevent it by not allowing
> > the os to recognize the device (aka removing the device info from the
> > TWAIN driver). That seems sleazy, but given what you've just said it
> > might be my only option.
> >
> > Thanks for your input.
> >
> >
> >>
> >> -Nathan
> >>
> >> On Jan 31, 2012, at 5:42 AM, Michael Lewis wrote:
> >>
> >>> I ran across a bug with OpenUSB on Mac OS X 10.7 recently. Basically,
> >>> I had two processes trying to keep the device open. I looked through
> >>> the code and found this:
> >>>
> >>> /* Try to actually open the device */
> >>> #if !defined (OPENUSB_NO_SEIZE_DEVICE)
> >>> kresult = (*(hdev->priv->device))->USBDeviceOpenSeize (hdev->priv->device);
> >>> #else
> >>> /* No Seize in OS X 10.0 (Darwin 1.4) */
> >>> kresult = (*(hdev->priv->device))->USBDeviceOpen (hdev->priv->device);
> >>> #endif
> >>>
> >>> Is there any reason we can't always just use USBDeviceOpen to prevent
> >>> exclusive connections? I thought it might have to do with setting the
> >>> configuration, but my testing shows that the device will work just
> >>> fine with USBDeviceOpen.
> >>>
> >>> So, if there is a reason not to change it, please let me know and I
> >>> won't, otherwise I will probably submit the change in a few days.
> >>>
> >>>
> >>> --Mike Lewis
> >>> "Be who you are and say what you feel, because those who mind don't
> >>> matter and those who matter don't mind." --Dr. Seuss
> >>>
> >>> ------------------------------------------------------------------------------

Segher Boessenkool

Re: OpenUSB / LibUSB on Mac OS X

In reply to this post by Nathan Hjelm-2

> BTW, why would two processes want to open the same device? Only one
> process at a time can send control messages to a device at one time
> on MacOS X.

One example is when you have an FT2232 with two logically
independent serial devices attached, e.g. a JTAG and a UART.
Operating either requires you to send control messages to
the device. OSX allows you to do that, but it does not work
with current libusb.

Segher

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Nathan Hjelm-2

Re: OpenUSB / LibUSB on Mac OS X

Well, the requirements for sending a control message is that the device is open. When I wrote the libusb backend I assumed that meant the device must be opened by the current process (not some other process). I see no reason not to change the backend implementation if that assumption is wrong.

-Nathan

On Jan 31, 2012, at 9:13 PM, Segher Boessenkool wrote:

>> BTW, why would two processes want to open the same device? Only one process at a time can send control messages to a device at one time on MacOS X.
>
> One example is when you have an FT2232 with two logically
> independent serial devices attached, e.g. a JTAG and a UART.
> Operating either requires you to send control messages to
> the device. OSX allows you to do that, but it does not work
> with current libusb.
>
>
> Segher
>

Vitali Lovich-2

Re: OpenUSB / LibUSB on Mac OS X

Yeah - I would say that you should have the core driver implementation in 1 process & then use IPC to co-ordinate amongst other processes. I tend to think of libusb as a user-space driver API; do you ever have 2 kernel drivers active for the same device?

-Vitali

On Jan 31, 2012, at 8:56 PM, Nathan Hjelm wrote:

> Well, the requirements for sending a control message is that the device is open. When I wrote the libusb backend I assumed that meant the device must be opened by the current process (not some other process). I see no reason not to change the backend implementation if that assumption is wrong.
>
> -Nathan
>
> On Jan 31, 2012, at 9:13 PM, Segher Boessenkool wrote:
>
>>> BTW, why would two processes want to open the same device? Only one process at a time can send control messages to a device at one time on MacOS X.
>>
>> One example is when you have an FT2232 with two logically
>> independent serial devices attached, e.g. a JTAG and a UART.
>> Operating either requires you to send control messages to
>> the device. OSX allows you to do that, but it does not work
>> with current libusb.
>>
>>
>> Segher
>>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

Xiaofan Chen

Re: OpenUSB / LibUSB on Mac OS X

In reply to this post by Nathan Hjelm-2

On Wed, Feb 1, 2012 at 12:56 PM, Nathan Hjelm <[hidden email]> wrote:

> On Jan 31, 2012, at 9:13 PM, Segher Boessenkool wrote:
>>> BTW, why would two processes want to open the same device?
>>> Only one process at a time can send control messages to a device
>>> at one time on MacOS X.
>>
>> One example is when you have an FT2232 with two logically
>> independent serial devices attached, e.g. a JTAG and a UART.
>> Operating either requires you to send control messages to
>> the device. OSX allows you to do that, but it does not work
>> with current libusb.
>
> Well, the requirements for sending a control message is that the
> device is open. When I wrote the libusb backend I assumed that
> meant the device must be opened by the current process (not
> some other process). I see no reason not to change the backend
> implementation if that assumption is wrong.

So this is different issues with the past discussion (in 2009) where
it talks about multiple open with the same process space (different
threads). That problem has been solved, right?
http://libusb.6.n5.nabble.com/MacOSX-Accessing-multiple-interfaces-of-the-same-device-at-once-td8710.html

> USBDeviceOpenSeize is needed to cause the kernel driver to detach
> from the device (if the driver supports the feature) so I wouldn't change it.
> You might be able to close after the Seize and reopen immediately with
> USBDeviceOpen but the kernel driver might reattach.

Just wondering what kind of driver will allow the detach feature? Apparent
Apple HID driver does not have this feature.
http://stackoverflow.com/questions/3368008/reading-and-writing-to-usb-hid-interrupt-endpoints-on-mac

--
Xiaofan

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Xiaofan Chen

Re: OpenUSB / LibUSB on Mac OS X

In reply to this post by Vitali Lovich-2

On Wed, Feb 1, 2012 at 1:01 PM, Vitali Lovich <[hidden email]> wrote:
> Yeah - I would say that you should have the core driver implementation in
> 1 process & then use IPC to co-ordinate amongst other processes. I tend to
> think of libusb as a user-space driver API; do you ever have 2 kernel
> drivers active for the same device?

Just remember that those are USB composite device and they will be
multiple kernel drivers active for the same device.

For FT2232D which has one JTAG interface and one UART interface,
under Windows, three drivers will be active: composite parent,
D2XX and the the VCP driver.

Under Linux, there will be two drivers, one ftdi_sio (for the UART)
and one usbfs (for the JTAG).

--
Xiaofan

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Nathan Hjelm-2

Re: OpenUSB / LibUSB on Mac OS X

In reply to this post by Xiaofan Chen

On Jan 31, 2012, at 10:05 PM, Xiaofan Chen wrote:

So this is different issues with the past discussion (in 2009) where
it talks about multiple open with the same process space (different
threads). That problem has been solved, right?
http://libusb.6.n5.nabble.com/MacOSX-Accessing-multiple-interfaces-of-the-same-device-at-once-td8710.html

Yes, multiple access from the same process space should be working.

USBDeviceOpenSeize is needed to cause the kernel driver to detach
from the device (if the driver supports the feature) so I wouldn't change it.
You might be able to close after the Seize and reopen immediately with
USBDeviceOpen but the kernel driver might reattach.

Just wondering what kind of driver will allow the detach feature? Apparent
Apple HID driver does not have this feature.
http://stackoverflow.com/questions/3368008/reading-and-writing-to-usb-hid-interrupt-endpoints-on-mac

Drivers that respond to the kIOServiceRequestingClose message support the feature. One example: http://www.opensource.apple.com/source/IOUSBFamily/IOUSBFamily-453.4.2/IOUSBCompositeDriver/Classes/IOUSBCompositeDriver.cpp

-Nathan

Xiaofan Chen

Re: OpenUSB / LibUSB on Mac OS X

On Wed, Feb 1, 2012 at 1:10 PM, Nathan Hjelm <[hidden email]> wrote:

> USBDeviceOpenSeize is needed to cause the kernel driver to detach
> from the device (if the driver supports the feature) so I wouldn't change
> it.
>
> You might be able to close after the Seize and reopen immediately with
> USBDeviceOpen but the kernel driver might reattach.
>
> Just wondering what kind of driver will allow the detach feature? Apparent
> Apple HID driver does not have this feature.
> http://stackoverflow.com/questions/3368008/reading-and-writing-to-usb-hid-interrupt-endpoints-on-mac
>
> Drivers that respond to the kIOServiceRequestingClose message support the
> feature. One example:
> http://www.opensource.apple.com/source/IOUSBFamily/IOUSBFamily-453.4.2/IOUSBCompositeDriver/Classes/IOUSBCompositeDriver.cpp

Thanks. That is interesting.

A google search shows that Mac OS X USB Mass Storage Class Driver
seems to support kIOMessageServiceIsRequestingClose. So does that
mean libusb applications can detach the kernel USB Mass Storage
Device driver without using a code-less kext, that would be interesting.

http://opensource.apple.com/source/IOUSBMassStorageClass/IOUSBMassStorageClass-1.1_12/IOUSBMassStorageClass.cpp

case kIOMessageServiceIsRequestingClose:
{
IOUSBInterface * currentInterface;

STATUS_LOG(("%s: message
kIOMessageServiceIsRequestingClose.\n", getName() ));

// Let the clients know that the device is gone.
SendNotification_DeviceRemoved( );

currentInterface = GetInterfaceReference();
if ( currentInterface != NULL )
{
SetInterfaceReference( NULL );

// Close our interface
currentInterface->close(this);
}

result = kIOReturnSuccess;
}
break;

The comments of the OpenBox Mac OS X USB Driver is
kind of interesting. Apparently it does not want other
process other than the VM process to seize the device
but IOKit does not really tell it the new client. So the
author says " We'll ASSUME this'll remain like this for now..."
Kind of interesting.

/*
* This message is send to the current IOService client from
IOService::handleOpen(),
* expecting it to call pProvider->close() if it agrees to the
other party seizing
* the service. It is also called in IOService::didTerminate()
and perhaps some other
* odd places. The way to find out is to examin the pvArg,
which would be including
* kIOServiceSeize if it's the handleOpen case.
*
* How to validate that the other end is actually our VM
process? Well, IOKit doesn't
* provide any clue about the new client really. But
fortunately, it seems like the
* calling task/process context when the VM tries to open the
device is the VM process.
* We'll ASSUME this'll remain like this for now...
*/
case kIOMessageServiceIsRequestingClose:
...

--
Xiaofan

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Michael Lewis

Re: OpenUSB / LibUSB on Mac OS X

On Wed, Feb 1, 2012 at 8:37 AM, Xiaofan Chen <[hidden email]> wrote:

> On Wed, Feb 1, 2012 at 1:10 PM, Nathan Hjelm <[hidden email]> wrote:
>> USBDeviceOpenSeize is needed to cause the kernel driver to detach
>> from the device (if the driver supports the feature) so I wouldn't change
>> it.
>>
>> You might be able to close after the Seize and reopen immediately with
>> USBDeviceOpen but the kernel driver might reattach.
>>
>> Just wondering what kind of driver will allow the detach feature? Apparent
>> Apple HID driver does not have this feature.
>> http://stackoverflow.com/questions/3368008/reading-and-writing-to-usb-hid-interrupt-endpoints-on-mac
>>
>> Drivers that respond to the kIOServiceRequestingClose message support the
>> feature. One example:
>> http://www.opensource.apple.com/source/IOUSBFamily/IOUSBFamily-453.4.2/IOUSBCompositeDriver/Classes/IOUSBCompositeDriver.cpp
>
> Thanks. That is interesting.
>
> A google search shows that Mac OS X USB Mass Storage Class Driver
> seems to support kIOMessageServiceIsRequestingClose. So does that
> mean libusb applications can detach the kernel USB Mass Storage
> Device driver without using a code-less kext, that would be interesting.
>
> http://opensource.apple.com/source/IOUSBMassStorageClass/IOUSBMassStorageClass-1.1_12/IOUSBMassStorageClass.cpp
>
> case kIOMessageServiceIsRequestingClose:
> {
> IOUSBInterface * currentInterface;
>
> STATUS_LOG(("%s: message
> kIOMessageServiceIsRequestingClose.\n", getName() ));
>
> // Let the clients know that the device is gone.
> SendNotification_DeviceRemoved( );
>
> currentInterface = GetInterfaceReference();
> if ( currentInterface != NULL )
> {
> SetInterfaceReference( NULL );
>
> // Close our interface
> currentInterface->close(this);
> }
>
> result = kIOReturnSuccess;
> }
> break;

So, will this method work in OpenUSB/Libusb (they are very much the
same at the low level)? I would definitely be interested in
implementing that, if it's not too difficult.

> The comments of the OpenBox Mac OS X USB Driver is
> kind of interesting. Apparently it does not want other
> process other than the VM process to seize the device
> but IOKit does not really tell it the new client. So the
> author says " We'll ASSUME this'll remain like this for now..."
> Kind of interesting.
>
> /*
> * This message is send to the current IOService client from
> IOService::handleOpen(),
> * expecting it to call pProvider->close() if it agrees to the
> other party seizing
> * the service. It is also called in IOService::didTerminate()
> and perhaps some other
> * odd places. The way to find out is to examin the pvArg,
> which would be including
> * kIOServiceSeize if it's the handleOpen case.
> *
> * How to validate that the other end is actually our VM
> process? Well, IOKit doesn't
> * provide any clue about the new client really. But
> fortunately, it seems like the
> * calling task/process context when the VM tries to open the
> device is the VM process.
> * We'll ASSUME this'll remain like this for now...
> */
> case kIOMessageServiceIsRequestingClose:
> ...
>
>
> --
> Xiaofan
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

Segher Boessenkool

Re: OpenUSB / LibUSB on Mac OS X

In reply to this post by Nathan Hjelm-2

>>> BTW, why would two processes want to open the same device? Only
>>> one process at a time can send control messages to a device at
>>> one time on MacOS X.
>>
>> One example is when you have an FT2232 with two logically
>> independent serial devices attached, e.g. a JTAG and a UART.
>> Operating either requires you to send control messages to
>> the device. OSX allows you to do that, but it does not work
>> with current libusb.

> Well, the requirements for sending a control message is that the
> device is open. When I wrote the libusb backend I assumed that
> meant the device must be opened by the current process (not some
> other process). I see no reason not to change the backend
> implementation if that assumption is wrong.

I guess I didn't explain properly.

Both my processes call libusb_open() and libusb_claim_interface()
(with different interfaces of course). On Linux this works fine.
On OSX all control transfers (including libusb_get_string_descriptor())
fail. If I change the libusb code to handle kIOReturnExclusiveAccess
from USBDeviceOpenSeize() exactly like kIOReturnSuccess, everything
works for me.

This has come up a few times now, do you still want to keep it
like this because the OSX documentation says the control transfers
can fail if the device is not exclusively opened? Every version
of OSX allows it just fine, and Linux has the same behaviour.
Plus it is quite useful behaviour :-)

Segher

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Xiaofan Chen

Re: OpenUSB / LibUSB on Mac OS X

In reply to this post by Michael Lewis

On Wed, Feb 1, 2012 at 10:38 PM, Michael Lewis <[hidden email]> wrote:

>>> USBDeviceOpenSeize is needed to cause the kernel driver to detach
>>> from the device (if the driver supports the feature) so I wouldn't change
>>> it.
>>>
>>> You might be able to close after the Seize and reopen immediately with
>>> USBDeviceOpen but the kernel driver might reattach.
>>>
>>> Drivers that respond to the kIOServiceRequestingClose message
>>> support the feature.
>
> So, will this method work in OpenUSB/Libusb (they are very much the
> same at the low level)? I would definitely be interested in
> implementing that, if it's not too difficult.
>

I am thinking that kIOMessageServiceIsRequestingClose
is reserved for the kernel drivers so it will not be possible
with libusb/OpenUSB.

--
Xiaofan

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Xiaofan Chen

Re: OpenUSB / LibUSB on Mac OS X

In reply to this post by Xiaofan Chen

On Wed, Feb 1, 2012 at 9:37 PM, Xiaofan Chen <[hidden email]> wrote:

> On Wed, Feb 1, 2012 at 1:10 PM, Nathan Hjelm <[hidden email]> wrote:
>> USBDeviceOpenSeize is needed to cause the kernel driver to detach
>> from the device (if the driver supports the feature) so I wouldn't change
>> it.
>>
>> You might be able to close after the Seize and reopen immediately with
>> USBDeviceOpen but the kernel driver might reattach.
>>
>> Just wondering what kind of driver will allow the detach feature? Apparent
>> Apple HID driver does not have this feature.
>> http://stackoverflow.com/questions/3368008/reading-and-writing-to-usb-hid-interrupt-endpoints-on-mac
>>
>> Drivers that respond to the kIOServiceRequestingClose message support the
>> feature. One example:
>> http://www.opensource.apple.com/source/IOUSBFamily/IOUSBFamily-453.4.2/IOUSBCompositeDriver/Classes/IOUSBCompositeDriver.cpp
>
> Thanks. That is interesting.
>
> A google search shows that Mac OS X USB Mass Storage Class Driver
> seems to support kIOMessageServiceIsRequestingClose. So does that
> mean libusb applications can detach the kernel USB Mass Storage
> Device driver without using a code-less kext? That would be interesting.
>
> http://opensource.apple.com/source/IOUSBMassStorageClass/IOUSBMassStorageClass-1.1_12/IOUSBMassStorageClass.cpp
>
> case kIOMessageServiceIsRequestingClose:
> {
> IOUSBInterface * currentInterface;
>
> STATUS_LOG(("%s: message
> kIOMessageServiceIsRequestingClose.\n", getName() ));
>
> // Let the clients know that the device is gone.
> SendNotification_DeviceRemoved( );
>
> currentInterface = GetInterfaceReference();
> if ( currentInterface != NULL )
> {
> SetInterfaceReference( NULL );
>
> // Close our interface
> currentInterface->close(this);
> }
>
> result = kIOReturnSuccess;
> }
> break;
>

The handy example is the xusb.c from libusb-pbatard. Unfortunately it
does not seem to work under Mac OS X.

The problem seems to point to darwin_cache_device_descriptor.

mymacmini:examples xiaofanc$ ./xusb -b 0781:5151
Using libusb v1.0.8.10349

libusb:debug [libusb_init] created default context
libusb:debug [libusb_init]
libusb:info [event_thread_main] creating hotplug event source
libusb:info [event_thread_main] thread ready to receive events
libusb:debug [usbi_add_pollfd] add fd 4 events 1
Opening device...
libusb:debug [libusb_get_device_list]
libusb:info [process_new_device] allocating new device for location 0xfa000000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x09
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x01
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x40
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x05ac
libusb:debug [darwin_cache_device_descriptor] idProduct: 0x8006
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x0200
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x02
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x01
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 1 port = 0
parent = 0x7fec84903f08 at 0x0
libusb:info [process_new_device] allocating new device for location 0xfa100000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x09
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x02
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x40
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x0424
libusb:debug [darwin_cache_device_descriptor] idProduct: 0x2513
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x0bb3
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x00
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x00
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 2 port = 1
parent = 0x7fec84903298 at 0x7fec84903e70
libusb:info [process_new_device] allocating new device for location 0xfa110000
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe00002ed. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe00002ed. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe00002ed. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] could not retrieve
device descriptor 0a5c:4500: device not responding. skipping device
libusb:debug [libusb_unref_device] destroy device 0.0
libusb:info [process_new_device] allocating new device for location 0xfa130000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x09
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x01
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x40
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x05e3
libusb:debug [darwin_cache_device_descriptor] idProduct: 0x0606
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x0702
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x00
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x01
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 4 port = 3
parent = 0x7fec84903148 at 0x7fec84903200
libusb:info [process_new_device] allocating new device for location 0xfa120000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x00
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x08
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x04f2
libusb:debug [darwin_cache_device_descriptor] idProduct: 0x0760
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x0100
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x01
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x02
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 5 port = 2
parent = 0x7fec82c0a398 at 0x7fec84903200
libusb:info [process_new_device] allocating new device for location 0xfa113000
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe00002ed. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe00002ed. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe00002ed. sleeping for 30 ms before trying again
libusb:warning [darwin_cache_device_descriptor] could not retrieve
device descriptor 05ac:8281: device not responding. skipping device
libusb:debug [libusb_unref_device] destroy device 0.0
libusb:info [process_new_device] allocating new device for location 0xfa132000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x00
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x08
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x046d
libusb:debug [darwin_cache_device_descriptor] idProduct: 0xc52f
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x2200
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x01
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x02
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 6 port = 2
parent = 0x7fec82c0a5f8 at 0x0
libusb:info [process_new_device] allocating new device for location 0xfa134000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x00
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x08
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x046d
libusb:debug [darwin_cache_device_descriptor] idProduct: 0xc054
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x5400
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x01
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x02
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 8 port = 4
parent = 0x7fec84903418 at 0x0
libusb:info [process_new_device] allocating new device for location 0xfa131000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x00
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x40
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x0781
libusb:debug [darwin_cache_device_descriptor] idProduct: 0x5151
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x0200
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x01
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x02
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x03
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 9 port = 1
parent = 0x7fec84903358 at 0x0
libusb:info [process_new_device] allocating new device for location 0xfd000000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x09
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x01
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x40
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x05ac
libusb:debug [darwin_cache_device_descriptor] idProduct: 0x8006
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x0200
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x02
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x01
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 1 port = 0
parent = 0x7fec848005d8 at 0x0
libusb:info [process_new_device] allocating new device for location 0xfd100000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x09
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x02
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x40
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x0424
libusb:debug [darwin_cache_device_descriptor] idProduct: 0x2513
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x0bb3
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x00
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x00
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:debug [discovered_devs_append] need to increase capacity
libusb:info [process_new_device] found device with address 2 port = 1
parent = 0x7fec84800408 at 0x7fec84800540
libusb:info [process_new_device] allocating new device for location 0xfd110000
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x00
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x08
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x05ac
libusb:debug [darwin_cache_device_descriptor] idProduct: 0x8242
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x0016
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x01
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x02
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 3 port = 1
parent = 0x7fec82c0a6b8 at 0x7fec84800370
libusb:info [process_new_device] allocating new device for location 0xfd120000
libusb:debug [darwin_cache_device_descriptor] device descriptor:
libusb:debug [darwin_cache_device_descriptor] bDescriptorType: 0x01
libusb:debug [darwin_cache_device_descriptor] bcdUSB: 0x0200
libusb:debug [darwin_cache_device_descriptor] bDeviceClass: 0xef
libusb:debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x02
libusb:debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x01
libusb:debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x40
libusb:debug [darwin_cache_device_descriptor] idVendor: 0x0ac8
libusb:debug [darwin_cache_device_descriptor] idProduct: 0x3420
libusb:debug [darwin_cache_device_descriptor] bcdDevice: 0x0100
libusb:debug [darwin_cache_device_descriptor] iManufacturer: 0x01
libusb:debug [darwin_cache_device_descriptor] iProduct: 0x02
libusb:debug [darwin_cache_device_descriptor] iSerialNumber: 0x00
libusb:debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01
libusb:info [darwin_check_configuration] active config: 1, first config: 1
libusb:info [process_new_device] found device with address 4 port = 2
parent = 0x7fec82c0a498 at 0x7fec84800370
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_unref_device] destroy device 250.1
libusb:debug [libusb_unref_device] destroy device 250.2
libusb:debug [libusb_unref_device] destroy device 250.4
libusb:debug [libusb_unref_device] destroy device 250.5
libusb:debug [libusb_unref_device] destroy device 250.6
libusb:debug [libusb_unref_device] destroy device 250.8
libusb:debug [libusb_unref_device] destroy device 250.9
libusb:debug [libusb_unref_device] destroy device 253.1
libusb:debug [libusb_unref_device] destroy device 253.2
libusb:debug [libusb_unref_device] destroy device 253.3
libusb:debug [libusb_unref_device] destroy device 253.4
Failed.
libusb:debug [libusb_exit]
libusb:debug [libusb_exit] destroying default context
libusb:debug [usbi_remove_pollfd] remove fd 4
libusb:info [event_thread_main] thread exiting

--
Xiaofan

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Xiaofan Chen

Re: OpenUSB / LibUSB on Mac OS X

On Sun, Feb 5, 2012 at 10:52 PM, Xiaofan Chen <[hidden email]> wrote:
>> A google search shows that Mac OS X USB Mass Storage Class Driver
>> seems to support kIOMessageServiceIsRequestingClose. So does that
>> mean libusb applications can detach the kernel USB Mass Storage
>> Device driver without using a code-less kext? That would be interesting.
>>
> The handy example is the xusb.c from libusb-pbatard. Unfortunately it
> does not seem to work under Mac OS X.

I mean the detach of kernel driver does not seem to work for
USB mass storage device.

> The problem seems to point to darwin_cache_device_descriptor.

That is not correct. I should have said that "there seems to be a problem
with 05ac:8281".

libusb:info [process_new_device] allocating new device for location 0xfa113000
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe00002ed. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe00002ed. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe000404f. sleeping for 30 ms before trying again
libusb:debug [darwin_cache_device_descriptor] kernel responded with
code: 0xe00002ed. sleeping for 30 ms before trying again
libusb:warning [darwin_cache_device_descriptor] could not retrieve
device descriptor 05ac:8281: device not responding. skipping device
libusb:debug [libusb_unref_device] destroy device 0.0

Actually it is the Apple Bluetooth controller. Once I turned on
bluetooth, the problem goes away.

--
Xiaofan

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel