libusbx-devel — libusbx development mailing list

[Libusbx-devel] Announce libusb-1.0.20

[Chris D. <chr...@gm...>]

Hi All,

I'm pleased to announce the libusb-1.0.20 final release.

It has been over a year since the last release, and a lot of changes have
gone in during that time (95 commits).

Changelog:
* Add Haiku support
* Fix multiple memory and resource leaks (#16, #52, #76, #81)
* Fix possible deadlock when executing transfer callback
* New libusb_free_pollfds() API
* Darwin: Fix devices not being detected on OS X 10.8 (#48)
* Linux: Allow larger isochronous transfer submission (#23)
* Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings
* Windows: Fix broken bus number lookup
* Windows: Improve submission of control requests for composite devices
* Examples: Add two-stage load support to fxload (#12)
* Correctly report cancellations due to timeouts
* Improve efficiency of event handling
* Improve speed of transfer submission in multi-threaded environments
* Various other bug fixes and improvements
The (#xx) numbers are libusb issue numbers, see ie:
https://github.com/libusb/libusb/issues/16

You can download the source code here:

https://github.com/libusb/libusb/releases/download/v1.0.20/libusb-1.0.20.tar.bz2
http://downloads.sourceforge.net/libusb/libusb-1.0.20.tar.bz2

The Windows binary tarball is available here:

https://github.com/libusb/libusb/releases/download/v1.0.20/libusb-1.0.20.7z
http://downloads.sourceforge.net/libusb/libusb-1.0.20.7z

Regards,
Chris

Re: [Libusbx-devel] Compiling the libu

[Pradeepa S. <pra...@gm...>]

Hello Chris,

Thank you for the suggestion. We compiled libusb-1.0.19 using
--disable-udev option on our device. It works well.



Best Regards,
Pradeepa Senanayake.

On Thu, Sep 3, 2015 at 10:22 AM, Chris Dickens <
chr...@gm...> wrote:

> Hi,
>
> On Wed, Sep 2, 2015 at 9:14 PM, Pradeepa Senanayake <
> pra...@gm...> wrote:
>
>> We are trying to install the latest libusbx package (1.0.18) to our
>> system. But we found out that there is a dependency for libudev. Since that
>> lib is not available in our current BSP we cannot install libusbx at the
>> moment.
>>
>> But we can install libusb 1.0.15 (which too has an issue which I will
>> post separately). Is there anyway we can disable the libudev dependency
>> using configure options and build the libusbx-1.0.18 package? Is the change
>> from 1.0.15 to 1.0.18 substantial?
>>
>
> libusb versions 1.0.16 and later require at least netlink support on
> Linux. You can pass configure the '--disable-udev' flag to select netlink
> instead.
>
> There have been many changes from v1.0.15 to v1.0.18. The latest (libusb)
> is now v1.0.20-rc2. I encourage you to try that.
>
> For future issues, please use the libusb-devel mailing list instead of
> libusbx-devel. libusbx is now obsolete.
>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> libusbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
>

Re: [Libusbx-devel] Announcing libusb-1.0.20-rc3

[Jie Z. <jzh...@gm...>]

Parallel build fails. See below for the log.

Jie


jie@elf:~/sources/libusb-1.0.20-rc3$ ./configure
[...]
jie@elf:~/sources/libusb-1.0.20-rc3$ make -j4
make  all-recursive
make[1]: Entering directory `/home/jie/sources/libusb-1.0.20-rc3'
Making all in libusb
make[2]: Entering directory `/home/jie/sources/libusb-1.0.20-rc3/libusb'
  CC       libusb_1_0_la-core.lo
  CC       libusb_1_0_la-descriptor.lo
  CC       libusb_1_0_la-io.lo
make[3]: Entering directory `/home/jie/sources/libusb-1.0.20-rc3/libusb'
  CC       libusb_1_0_la-core.lo
  CC       libusb_1_0_la-strerror.lo
  CC       libusb_1_0_la-sync.lo
mv: cannot stat `.deps/libusb_1_0_la-core.Tpo': No such file or directory
make[3]: *** [libusb_1_0_la-core.lo] Error 1
make[3]: Leaving directory `/home/jie/sources/libusb-1.0.20-rc3/libusb'
make[2]: *** [all-recursive] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/jie/sources/libusb-1.0.20-rc3/libusb'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jie/sources/libusb-1.0.20-rc3'
make: *** [all] Error 2

On Sat, Sep 5, 2015 at 1:44 PM, Chris Dickens
<chr...@gm...> wrote:
> Hi All,
>
> I'm pleased to announce the libusb-1.0.20-rc3 release. This release comes
> soon after rc2 to address a regression found in the previous releases.
>
> It has been over a year since the last release, and a lot of changes have
> gone in during that time (95 commits).
>
> Changelog:
> * Add Haiku support
> * Fix multiple memory and resource leaks (#16, #52, #76, #81)
> * Fix possible deadlock when executing transfer callback
> * New libusb_free_pollfds() API
> * Darwin: Fix devices not being detected on OS X 10.8 (#48)
> * Linux: Allow larger isochronous transfer submission (#23)
> * Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings
> * Windows: Fix broken bus number lookup
> * Windows: Improve submission of control requests for composite devices
> * Examples: Add two-stage load support to fxload (#12)
> * Correctly report cancellations due to timeouts
> * Improve efficiency of event handling
> * Improve speed of transfer submission in multi-threaded environments
> * Various other bug fixes and improvements
> The (#xx) numbers are libusb issue numbers, see ie:
> https://github.com/libusb/libusb/issues/16
>
> Changes since rc2:
> * Fix regression when using timerfd for timeouts with multiple transfers
> * Windows: Fix build warnings/link issues
>
> You can download the 1.0.20-rc3 tarball here:
> https://github.com/libusb/libusb/releases/download/v1.0.20-rc3/libusb-1.0.20-rc3.tar.bz2
>
> Please test and let us know if you find any issues. With no reported issues
> we plan to release a final version of 1.0.20 in 1 week.
>
> Regards,
> Chris
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> libusbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>

[Libusbx-devel] Announcing libusb-1.0.20-rc3

[Chris D. <chr...@gm...>]

Hi All,

I'm pleased to announce the libusb-1.0.20-rc3 release. This release comes
soon after rc2 to address a regression found in the previous releases.

It has been over a year since the last release, and a lot of changes have
gone in during that time (95 commits).

Changelog:
* Add Haiku support
* Fix multiple memory and resource leaks (#16, #52, #76, #81)
* Fix possible deadlock when executing transfer callback
* New libusb_free_pollfds() API
* Darwin: Fix devices not being detected on OS X 10.8 (#48)
* Linux: Allow larger isochronous transfer submission (#23)
* Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings
* Windows: Fix broken bus number lookup
* Windows: Improve submission of control requests for composite devices
* Examples: Add two-stage load support to fxload (#12)
* Correctly report cancellations due to timeouts
* Improve efficiency of event handling
* Improve speed of transfer submission in multi-threaded environments
* Various other bug fixes and improvements
The (#xx) numbers are libusb issue numbers, see ie:
https://github.com/libusb/libusb/issues/16

Changes since rc2:
* Fix regression when using timerfd for timeouts with multiple transfers
* Windows: Fix build warnings/link issues

You can download the 1.0.20-rc3 tarball here:
https://github.com/libusb/libusb/releases/download/v1.0.20-rc3/libusb-1.0.20-rc3.tar.bz2

Please test and let us know if you find any issues. With no reported issues
we plan to release a final version of 1.0.20 in 1 week.

Regards,
Chris

Re: [Libusbx-devel] Compiling the libu

[Chris D. <chr...@gm...>]

Hi,

On Wed, Sep 2, 2015 at 9:14 PM, Pradeepa Senanayake <
pra...@gm...> wrote:

> We are trying to install the latest libusbx package (1.0.18) to our
> system. But we found out that there is a dependency for libudev. Since that
> lib is not available in our current BSP we cannot install libusbx at the
> moment.
>
> But we can install libusb 1.0.15 (which too has an issue which I will post
> separately). Is there anyway we can disable the libudev dependency using
> configure options and build the libusbx-1.0.18 package? Is the change from
> 1.0.15 to 1.0.18 substantial?
>

libusb versions 1.0.16 and later require at least netlink support on Linux.
You can pass configure the '--disable-udev' flag to select netlink instead.

There have been many changes from v1.0.15 to v1.0.18. The latest (libusb)
is now v1.0.20-rc2. I encourage you to try that.

For future issues, please use the libusb-devel mailing list instead of
libusbx-devel. libusbx is now obsolete.

Regards,
Chris

[Libusbx-devel] Compiling the libu

[Pradeepa S. <pra...@gm...>]

Hello,

We have a product which uses freescale iMX6 processor and the following
Linux BSP version.

root@freescale ~$ uname -a
Linux freescale 3.0.35-2666-gbdde708 #18 SMP PREEMPT Tue Sep 1 15:17:34 IST
2015 armv7l GNU/Linux

We are trying to install the latest libusbx package (1.0.18) to our system.
But we found out that there is a dependency for libudev. Since that lib is
not available in our current BSP we cannot install libusbx at the moment.

But we can install libusb 1.0.15 (which too has an issue which I will post
separately). Is there anyway we can disable the libudev dependency using
configure options and build the libusbx-1.0.18 package? Is the change from
1.0.15 to 1.0.18 substantial?

Thank you.
-Pradeepa

[Libusbx-devel] Announcing libusb-1.0.20-rc2

[Chris D. <chr...@gm...>]

Hi All,

I'm pleased to announce the libusb-1.0.20-rc2 release.

It has been over a year since the last release, and a lot of changes have
gone in during that time (92 commits).

Changelog:
* Add Haiku support
* Fix multiple memory and resource leaks (#16, #52, #76, #81)
* Fix possible deadlock when executing transfer callback
* New libusb_free_pollfds() API
* Darwin: Fix devices not being detected on OS X 10.8 (#48)
* Linux: Allow larger isochronous transfer submission (#23)
* Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings
* Windows: Fix broken bus number lookup
* Windows: Improve submission of control requests for composite devices
* Improve efficiency of event handling
* Improve speed of transfer submission in multi-threaded environments
* Various other bug fixes and improvements
The (#xx) numbers are libusb issue numbers, see ie:
https://github.com/libusb/libusb/issues/16

Changes since rc1:
* Examples: Add two-stage load support to fxload (#12)
* Correctly report cancellations due to timeouts

You can download the 1.0.20-rc2 tarball here:
https://github.com/libusb/libusb/releases/download/v1.0.20-rc2/libusb-1.0.20-rc2.tar.bz2

Please test and let us know if you find any issues. WIth no reported issues
we plan to release a final version of 1.0.20 in 1 week.

Regards,
Chris

Re: [Libusbx-devel] [libusb] Announcing libusb-1.0.20-rc1

[Sean M. <se...@ro...>]

On Wed, 29 Jul 2015 10:48:56 -0700, Chris Dickens said:

>I'm pleased to announce the libusb-1.0.20-rc1 release.
>
>It has been over a year since the last release, and a lot of changes have
>gone in during that time (86 commits).
>
>2015-07-29: v1.0.20
>* Add Haiku support
>* Fix multiple memory and resource leaks (#16, #52, #76, #81)
>* Fix possible deadlock when executing transfer callback
>* New libusb_free_pollfds() API
>* Darwin: Fix devices not being detected on OS X 10.8 (#48)
>* Linux: Allow larger isochronous transfer submission (#23)
>* Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings
>* Windows: Fix broken bus number lookup
>* Windows: Improve submission of control requests for composite devices
>* Improve efficiency of event handling
>* Improve speed of transfer submission in multi-threaded environments
>* Various other bug fixes and improvements
>The (#xx) numbers are libusb issue numbers, see ie:
>https://github.com/libusb/libusb/issues/16
>
>You can download the 1.0.20-rc1 tarball here:
>https://github.com/libusb/libusb/releases/download/v1.0.20-rc1/
>libusb-1.0.20-rc1.tar.bz2
>
>Please test and let us know if you find any issues. We plan to release a
>final version of 1.0.20 in the next 2-3 weeks.

So it is perhaps time to release an rc2...?

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: [Libusbx-devel] [libusb] Announcing libusb-1.0.20-rc1

[Sean M. <se...@ro...>]

On Wed, 29 Jul 2015 10:48:56 -0700, Chris Dickens said:

>I'm pleased to announce the libusb-1.0.20-rc1 release.

FWIW: we've tested over a few days now with OS X 10.6 through 10.11 betas and have found no issues (for our use cases).

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

[Libusbx-devel] Announcing libusb-1.0.20-rc1

[Chris D. <chr...@gm...>]

Hi All,

I'm pleased to announce the libusb-1.0.20-rc1 release.

It has been over a year since the last release, and a lot of changes have
gone in during that time (86 commits).

2015-07-29: v1.0.20
* Add Haiku support
* Fix multiple memory and resource leaks (#16, #52, #76, #81)
* Fix possible deadlock when executing transfer callback
* New libusb_free_pollfds() API
* Darwin: Fix devices not being detected on OS X 10.8 (#48)
* Linux: Allow larger isochronous transfer submission (#23)
* Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings
* Windows: Fix broken bus number lookup
* Windows: Improve submission of control requests for composite devices
* Improve efficiency of event handling
* Improve speed of transfer submission in multi-threaded environments
* Various other bug fixes and improvements
The (#xx) numbers are libusb issue numbers, see ie:
https://github.com/libusb/libusb/issues/16

You can download the 1.0.20-rc1 tarball here:
https://github.com/libusb/libusb/releases/download/v1.0.20-rc1/libusb-1.0.20-rc1.tar.bz2

Please test and let us know if you find any issues. We plan to release a
final version of 1.0.20 in the next 2-3 weeks.

Regards,
Chris

Re: [Libusbx-devel] [libusbx] break from never ending loop. fix #76. (#167)

[daves0 <not...@gi...>]

Here we are almost a year later, and the "not-found" error return from libusb_cancel_transfer is not being handled.  It appears efforts here were stopped because one person can cause this problem in a manner that also involves EFAULTs.  In the end, however, there's still a looping bug in libusb, is there not?

The loop can only be exited when a specific condition occurs / state is reached.  There is a function call within the loop that can return a "not-found" value that indicates that the desired completion state will never be achieved.  This return value is ignored.  Sounds like a bug to me, no?

Can someone please correctly handle the failure (not-found) return from libusb_cancel_transfer that's inside of sync_transfer_wait_for_completion in a manner such that the endless loop doesn't occur any more?

Thanks!

Dave


---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/167#issuecomment-66930480

Re: [Libusbx-devel] libusbx: error [cache_config_descriptors] could not access configuration descriptor

[Tim R. <ti...@pr...>]

Qian Peng wrote:
>
> We have tried the lastest libusb and tested, the problem still exists.

libusb or libusbx?


> We found not only in the device enumeration phase will be stuck,
> sometimes also occur in the bulk transfer phase 995 error code 
> Related log is as follows:
> 2014-09-24 14:17:05:[00000a28]
> os/windows_usb.c:2067:windows_transfer_callback: handling I/O
> completion with errcode 995, size 0
> 2014-09-24 14:17:05:[00000a28]
> os/windows_usb.c:2090:windows_transfer_callback: detected operation
> aborted
>
> Errcode 995 always haunts us, we couldn't find the real cause of the
> problem.
> Could you please give us some ideas or tips to find the cause of the
> problem?

You're going to need to use a bus analyzer.  Your hardware is broken,
and you need to figure out why.  You can try a software analyzer first
(like usblyzer), but I'm guessing you'll need a hardware analyzer to get
to the bottom of this.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Re: [Libusbx-devel] libusbx: error [cache_config_descriptors] could not access configuration descriptor

[Qian P. <fl...@gm...>]

Sorry for late response.
We have tried the lastest libusb and tested, the problem still exists.
We found not only in the device enumeration phase will be stuck, sometimes
also occur in the bulk transfer phase 995 error code
Related log is as follows:
2014-09-24 14:17:05:[00000a28]
os/windows_usb.c:2067:windows_transfer_callback: handling I/O completion
with errcode 995, size 0
2014-09-24 14:17:05:[00000a28]
os/windows_usb.c:2090:windows_transfer_callback: detected operation aborted

Errcode 995 always haunts us, we couldn't find the real cause of the
problem.
Could you please give us some ideas or tips to find the cause of the
problem?

Thanks

2014-09-03 21:46 GMT+08:00 Pete Batard <pe...@ak...>:

> On 2014.09.03 09:35, Qian Peng wrote:
> > libusbx: error
>
> Looks like you are using libusbx, which has been superseded by libusb.
> Can you try with the latest libusb (Please visit http://libusb.info), in
> case it fixed that issue.
>
> > the issue looks like
> >
> http://sourceforge.net/p/libusbx/mailman/libusbx-devel/thread/1349577786.68914.1354005550176.JavaMail.open-xchange%40com4.strato.de/#msg30149384
> >
> > How do we avoid or solve the problem?
>
> As advised in the thread you point out, you may want to have a look at
> what USBView reports.
>
> Also, the device you are trying to access appears to be a "Kingston
> DataTraveler 2.0 Stick (2GB)" (http://www.linux-usb.org/usb.ids ->
> 0930:6544), which is a mass storage device.
>
> Can you clarify why you are trying to access a regular mass storage
> device using libusb on Windows? This means having to replace the default
> Mass Storage driver with WinUSB and losing native access to device as a
> flash drive, which seems like an odd thing to try to do...
>
> Regards,
>
> /Pete
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> libusbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>

Re: [Libusbx-devel] libusbx: error [cache_config_descriptors] could not access configuration descriptor

[Pete B. <pe...@ak...>]

On 2014.09.03 09:35, Qian Peng wrote:
> libusbx: error

Looks like you are using libusbx, which has been superseded by libusb.
Can you try with the latest libusb (Please visit http://libusb.info), in 
case it fixed that issue.

> the issue looks like
> http://sourceforge.net/p/libusbx/mailman/libusbx-devel/thread/1349577786.68914.1354005550176.JavaMail.open-xchange%40com4.strato.de/#msg30149384
>
> How do we avoid or solve the problem?

As advised in the thread you point out, you may want to have a look at 
what USBView reports.

Also, the device you are trying to access appears to be a "Kingston 
DataTraveler 2.0 Stick (2GB)" (http://www.linux-usb.org/usb.ids -> 
0930:6544), which is a mass storage device.

Can you clarify why you are trying to access a regular mass storage 
device using libusb on Windows? This means having to replace the default 
Mass Storage driver with WinUSB and losing native access to device as a 
flash drive, which seems like an odd thing to try to do...

Regards,

/Pete

[Libusbx-devel] libusbx: error [cache_config_descriptors] could not access configuration descriptor

[Qian P. <fl...@gm...>]

Hi all :)

We're using spice USB redirect function and find USB devices can't be
redirected sometimes.

When plug a USB device, spice client(in XP) can sense and call
libusb_get_device_list()

libusb log is as follows:
2014-09-02 10:44:31:[000008f8]
os/windows_usb.c:1465:windows_get_device_list: PRO:
\\.\USB#VID_0930&PID_6544#7E5BE265445FCD90E3AA4DEE
2014-09-02 10:44:31:[000008f8]
os/windows_usb.c:1510:windows_get_device_list: extra GUID:
{F301EA50-83E7-461E-A909-630FB2A1C2A6}
2014-09-02 10:44:31:[000008f8]
os/windows_usb.c:1574:windows_get_device_list: allocating new device for
session [24F]
2014-09-02 10:44:31:[000008f8] os/windows_usb.c:1166:init_device: found 1
configurations (active conf: 1)
libusbx: error [cache_config_descriptors] could not access configuration
descriptor (actual) for
'\\.\USB#VID_0930&PID_6544#7E5BE265445FCD90E3AA4DEE': [995]
ԉԚПԌ΋ԶܲӦԃԌѲȫȳìӑ؅Ǻ I/O әطc
(block about 5s)

At the beginning the device can be redirected, but we open and close spice
client process several times, this problem will occur. After re-plug the
usb device, the problem disappears.

the issue looks like
http://sourceforge.net/p/libusbx/mailman/libusbx-devel/thread/1349577786.68914.1354005550176.JavaMail.open-xchange%40com4.strato.de/#msg30149384

How do we avoid or solve the problem?

Thanks in advance!

Re: [Libusbx-devel] Getting "unsupported API call for 'open'" on Windows 8.1 libusb

[Xiaofan C. <xia...@gm...>]

On Wed, Aug 6, 2014 at 9:08 AM, Bob Tausworthe <to...@se...> wrote:
> Thank you for the reply. Sorry for the confusion. I am using lib usb 1.0.19.
> I guess I am on the wrong mailing list. So many flavors of open source...
> what is the correct list for lib usb for windows? Can I transfer the thread
> or do I need to repost in the correct list?

You can use libusb-devel.
https://lists.sourceforge.net/lists/listinfo/libusb-devel

You will have to repost in the libusb-devel list.

-- 
Xiaofan

Re: [Libusbx-devel] Getting "unsupported API call for 'open'" on Windows 8.1 libusb

[Bob T. <to...@se...>]

Thank you for the reply. Sorry for the confusion. I am using lib usb
1.0.19. I guess I am on the wrong mailing list. So many flavors of open
source... what is the correct list for lib usb for windows? Can I transfer
the thread or do I need to repost in the correct list?

Bob Tausworthe
On Aug 5, 2014 5:57 PM, "Xiaofan Chen" <xia...@gm...> wrote:

> On Wed, Jul 30, 2014 at 5:28 AM, Bob Tausworthe <to...@se...> wrote:
> > Sorry to trouble you but I've exhausted other options. We are developing
> a
> > composite HID/debug interace device and are using libusb 1.0 under 32 bit
> > Cygwin to access the debug interface portion. Everything is working fine
> on
> > Windows 7 and Linux but when we try to run the application on Windows 8,
> it
> > fails with the error :
> >
> > libusb: debug [unsupported_open] unsupported API call for 'open'
> > (unrecognized device driver)
> > libusb: debug [libusb_open] open 2.16 returns -12
> > ERROR: Unable to open usb device
> >
> > After reading some posts of people with similar issues, I tried all of
> the
> > drivers Zadig supports but didn't see any difference in behavior. I have
> > tried building under Win7 and Win8 but the results are the same. I am
> using
> > version 1.0.18 of libusb. The trace below was taken with the WinUSB
> driver
> > version 6.1.7600.16385.
> >
>
> libusbx is no longer been updated since it has merged back to libusb.
> You should try libusb-1.0.19 first to see if that helps.
> http://sourceforge.net/projects/libusb/files/libusb-1.0/
>
> --
> Xiaofan
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> libusbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>

Re: [Libusbx-devel] Getting "unsupported API call for 'open'" on Windows 8.1 libusb

[Xiaofan C. <xia...@gm...>]

On Wed, Jul 30, 2014 at 5:28 AM, Bob Tausworthe <to...@se...> wrote:
> Sorry to trouble you but I've exhausted other options. We are developing a
> composite HID/debug interace device and are using libusb 1.0 under 32 bit
> Cygwin to access the debug interface portion. Everything is working fine on
> Windows 7 and Linux but when we try to run the application on Windows 8, it
> fails with the error :
>
> libusb: debug [unsupported_open] unsupported API call for 'open'
> (unrecognized device driver)
> libusb: debug [libusb_open] open 2.16 returns -12
> ERROR: Unable to open usb device
>
> After reading some posts of people with similar issues, I tried all of the
> drivers Zadig supports but didn't see any difference in behavior. I have
> tried building under Win7 and Win8 but the results are the same. I am using
> version 1.0.18 of libusb. The trace below was taken with the WinUSB driver
> version 6.1.7600.16385.
>

libusbx is no longer been updated since it has merged back to libusb.
You should try libusb-1.0.19 first to see if that helps.
http://sourceforge.net/projects/libusb/files/libusb-1.0/

-- 
Xiaofan

Re: [Libusbx-devel] Getting "unsupported API call for 'open'" on Windows 8.1 libusb

[Matthias B. <mat...@go...>]

Hi, I had a similar problem a while ago, but my device look-up
strategy was a bit different. My problem was related to a driver bug
that made the Window API report the same hub port for two devices.
This should be impossible and confused libusb, as it assumes that hub
ports are unique. In the end I got the same error as you, because I
tried to open a device for which libusb didn't assign the proper
backend to. This made the open call fail with an unsupported error.

Anyway, you said this problem only occurs on Windows 8. How do you
test the different operating systems? Do you use different virtual
machines, or do you use different physical PCs? Maybe Windows 8 is not
the problem, but you're testing Windows 8 on a PC that has a USB host
controller with a buggy driver.

Things you could test:

- Test Windows 8 on different hardware.

- Test with your device connected to a different USB port, if it's
connected to a USB3 port then try a USB2 port.

- If you're testing Windows 8 in a virtual machine then try with
Windows 8 on an actual PC, maybe the problem is in the USB
pass-through of the virtual machine.

- In the for loop where you call is_correctdev(), don't break on the
first matching device, but check all devices in the list to see if
libusb reports multiple matching ones. If it does and you only have
one device actually connected, then you might have a similar problem
compared to the problem I had.

- Did you try the xusb examples that comes with libusb? Is xusb able
to list information about your device?

Some more things to test. This should not make a difference, but I
suggest testing it anyway:

- Simplify your test program: remove the config descriptor stuff
before the libusb_open() call.

- You said you're using cygwin, try without cygwin.

Regards,
Matthias


2014-08-02 3:18 GMT+02:00 Bob Tausworthe <to...@se...>:
> Hi, it checks the VID and PID
>
> int is_correctdev( libusb_device *dev )
> {
> struct libusb_device_descriptor desc;
> int r = libusb_get_device_descriptor( dev, &desc );
>
>     //printf("Checking VID=0x%04x, PID=0x%04x\n", desc.idVendor,
> desc.idProduct);
> if( desc.idVendor == VENDOR_ID &&
>       (desc.idProduct  == PRODUCT_ID)
>   {
>         //printf("device found: class=0x%x\n", desc.bDeviceClass);
>
> return 1;
> }
> return 0;
> }
>
>
>
> On Thu, Jul 31, 2014 at 3:42 AM, Matthias Bolte
> <mat...@go...> wrote:
>>
>> 2014-07-29 23:28 GMT+02:00 Bob Tausworthe <to...@se...>:
>> > Sorry to trouble you but I've exhausted other options. We are developing
>> > a
>> > composite HID/debug interace device and are using libusb 1.0 under 32
>> > bit
>> > Cygwin to access the debug interface portion. Everything is working fine
>> > on
>> > Windows 7 and Linux but when we try to run the application on Windows 8,
>> > it
>> > fails with the error :
>> >
>> > libusb: debug [unsupported_open] unsupported API call for 'open'
>> > (unrecognized device driver)
>> > libusb: debug [libusb_open] open 2.16 returns -12
>> > ERROR: Unable to open usb device
>> >
>> > After reading some posts of people with similar issues, I tried all of
>> > the
>> > drivers Zadig supports but didn't see any difference in behavior. I have
>> > tried building under Win7 and Win8 but the results are the same. I am
>> > using
>> > version 1.0.18 of libusb. The trace below was taken with the WinUSB
>> > driver
>> > version 6.1.7600.16385.
>> >
>> > Any help you can give me to point me in the right direction would be
>> > welcome. Here is the code I'm using to open our device and the trace
>> > listing.
>> >
>> > Thanks
>> >
>> > Bob Tausworthe
>> > to...@se...
>> > Sentons, inc.
>> >
>> > int
>> >
>> > InitUSB(void)
>> >
>> > {
>> >
>> >    // Change these as needed to match idVendor and idProduct in your
>> > device's device descriptor.
>> >
>> >    int device_ready = 0;
>> >
>> >    int result;
>> >
>> >   libusb_device **list;
>> >
>> >   libusb_device *found = NULL;
>> >
>> >   libusb_context *ctx = NULL;
>> >
>> >   int attached = 0;
>> >
>> >   result = libusb_init(&ctx);
>> >
>> >   if (result == 0) {
>> >
>> >   if (usb_trace_enabled)
>> >
>> >   libusb_set_debug(ctx,255); // LIBUSB_LOG_LEVEL_DEBUG,
>> > LIBUSB_LOG_LEVEL_WARNING
>> >
>> >   ssize_t i = 0;
>> >
>> >   int err = 0;
>> >
>> >   ssize_t cnt = libusb_get_device_list(ctx, &list);
>> >
>> >   if (cnt < 0){
>> >
>> >     fprintf(stderr, "ERROR: no usb devices found\n" );
>> >
>> >     error();
>> >
>> >   }
>> >
>> >   // find our device. Note we are using the brute force method rather
>> >
>> >   // than open_device_with_vid_pid() because we need the device pointer
>> >
>> >   // to look at the config descriptor.
>> >
>> >   for(i = 0; i < cnt; i++){
>> >
>> >     libusb_device *device = list[i];
>> >
>> >     if( is_correctdev(device) ){
>>
>> How does the is_correctdev() function decide which device to pick?
>>
>> --
>> Matthias Bolte
>> http://photron.blogspot.com
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> libusbx-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> libusbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>



-- 
Matthias Bolte
http://photron.blogspot.com

Re: [Libusbx-devel] Getting "unsupported API call for 'open'" on Windows 8.1 libusb

[Bob T. <to...@se...>]

Hi, it checks the VID and PID

int is_correctdev( libusb_device *dev )
{
struct libusb_device_descriptor desc;
int r = libusb_get_device_descriptor( dev, &desc );

    //printf("Checking VID=0x%04x, PID=0x%04x\n", desc.idVendor,
desc.idProduct);
if( desc.idVendor == VENDOR_ID &&
      (desc.idProduct  == PRODUCT_ID)
  {
        //printf("device found: class=0x%x\n", desc.bDeviceClass);

return 1;
}
return 0;
}



On Thu, Jul 31, 2014 at 3:42 AM, Matthias Bolte <
mat...@go...> wrote:

> 2014-07-29 23:28 GMT+02:00 Bob Tausworthe <to...@se...>:
> > Sorry to trouble you but I've exhausted other options. We are developing
> a
> > composite HID/debug interace device and are using libusb 1.0 under 32 bit
> > Cygwin to access the debug interface portion. Everything is working fine
> on
> > Windows 7 and Linux but when we try to run the application on Windows 8,
> it
> > fails with the error :
> >
> > libusb: debug [unsupported_open] unsupported API call for 'open'
> > (unrecognized device driver)
> > libusb: debug [libusb_open] open 2.16 returns -12
> > ERROR: Unable to open usb device
> >
> > After reading some posts of people with similar issues, I tried all of
> the
> > drivers Zadig supports but didn't see any difference in behavior. I have
> > tried building under Win7 and Win8 but the results are the same. I am
> using
> > version 1.0.18 of libusb. The trace below was taken with the WinUSB
> driver
> > version 6.1.7600.16385.
> >
> > Any help you can give me to point me in the right direction would be
> > welcome. Here is the code I'm using to open our device and the trace
> > listing.
> >
> > Thanks
> >
> > Bob Tausworthe
> > to...@se...
> > Sentons, inc.
> >
> > int
> >
> > InitUSB(void)
> >
> > {
> >
> >    // Change these as needed to match idVendor and idProduct in your
> > device's device descriptor.
> >
> >    int device_ready = 0;
> >
> >    int result;
> >
> >   libusb_device **list;
> >
> >   libusb_device *found = NULL;
> >
> >   libusb_context *ctx = NULL;
> >
> >   int attached = 0;
> >
> >   result = libusb_init(&ctx);
> >
> >   if (result == 0) {
> >
> >   if (usb_trace_enabled)
> >
> >   libusb_set_debug(ctx,255); // LIBUSB_LOG_LEVEL_DEBUG,
> > LIBUSB_LOG_LEVEL_WARNING
> >
> >   ssize_t i = 0;
> >
> >   int err = 0;
> >
> >   ssize_t cnt = libusb_get_device_list(ctx, &list);
> >
> >   if (cnt < 0){
> >
> >     fprintf(stderr, "ERROR: no usb devices found\n" );
> >
> >     error();
> >
> >   }
> >
> >   // find our device. Note we are using the brute force method rather
> >
> >   // than open_device_with_vid_pid() because we need the device pointer
> >
> >   // to look at the config descriptor.
> >
> >   for(i = 0; i < cnt; i++){
> >
> >     libusb_device *device = list[i];
> >
> >     if( is_correctdev(device) ){
>
> How does the is_correctdev() function decide which device to pick?
>
> --
> Matthias Bolte
> http://photron.blogspot.com
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> libusbx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>

Re: [Libusbx-devel] Getting "unsupported API call for 'open'" on Windows 8.1 libusb

[Matthias B. <mat...@go...>]

2014-07-29 23:28 GMT+02:00 Bob Tausworthe <to...@se...>:
> Sorry to trouble you but I've exhausted other options. We are developing a
> composite HID/debug interace device and are using libusb 1.0 under 32 bit
> Cygwin to access the debug interface portion. Everything is working fine on
> Windows 7 and Linux but when we try to run the application on Windows 8, it
> fails with the error :
>
> libusb: debug [unsupported_open] unsupported API call for 'open'
> (unrecognized device driver)
> libusb: debug [libusb_open] open 2.16 returns -12
> ERROR: Unable to open usb device
>
> After reading some posts of people with similar issues, I tried all of the
> drivers Zadig supports but didn't see any difference in behavior. I have
> tried building under Win7 and Win8 but the results are the same. I am using
> version 1.0.18 of libusb. The trace below was taken with the WinUSB driver
> version 6.1.7600.16385.
>
> Any help you can give me to point me in the right direction would be
> welcome. Here is the code I'm using to open our device and the trace
> listing.
>
> Thanks
>
> Bob Tausworthe
> to...@se...
> Sentons, inc.
>
> int
>
> InitUSB(void)
>
> {
>
>    // Change these as needed to match idVendor and idProduct in your
> device's device descriptor.
>
>    int device_ready = 0;
>
>    int result;
>
>   libusb_device **list;
>
>   libusb_device *found = NULL;
>
>   libusb_context *ctx = NULL;
>
>   int attached = 0;
>
>   result = libusb_init(&ctx);
>
>   if (result == 0) {
>
>   if (usb_trace_enabled)
>
>   libusb_set_debug(ctx,255); // LIBUSB_LOG_LEVEL_DEBUG,
> LIBUSB_LOG_LEVEL_WARNING
>
>   ssize_t i = 0;
>
>   int err = 0;
>
>   ssize_t cnt = libusb_get_device_list(ctx, &list);
>
>   if (cnt < 0){
>
>     fprintf(stderr, "ERROR: no usb devices found\n" );
>
>     error();
>
>   }
>
>   // find our device. Note we are using the brute force method rather
>
>   // than open_device_with_vid_pid() because we need the device pointer
>
>   // to look at the config descriptor.
>
>   for(i = 0; i < cnt; i++){
>
>     libusb_device *device = list[i];
>
>     if( is_correctdev(device) ){

How does the is_correctdev() function decide which device to pick?

-- 
Matthias Bolte
http://photron.blogspot.com

[Libusbx-devel] Getting "unsupported API call for 'open'" on Windows 8.1 libusb

[Bob T. <to...@se...>]

Sorry to trouble you but I've exhausted other options. We are developing a
composite HID/debug interace device and are using libusb 1.0 under 32 bit
Cygwin to access the debug interface portion. Everything is working fine on
Windows 7 and Linux but when we try to run the application on Windows 8, it
fails with the error :

libusb: debug [unsupported_open] unsupported API call for 'open'
(unrecognized device driver)
libusb: debug [libusb_open] open 2.16 returns -12
ERROR: Unable to open usb device

After reading some posts of people with similar issues, I tried all of the
drivers Zadig supports but didn't see any difference in behavior. I have
tried building under Win7 and Win8 but the results are the same. I am using
version 1.0.18 of libusb. The trace below was taken with the WinUSB driver
version 6.1.7600.16385.

Any help you can give me to point me in the right direction would be
welcome. Here is the code I'm using to open our device and the trace
listing.

Thanks

Bob Tausworthe
to...@se...
Sentons, inc.

int

InitUSB(void)

{

   // Change these as needed to match idVendor and idProduct in your
device's device descriptor.

   int device_ready = 0;

   int result;

  libusb_device **list;

  libusb_device *found = NULL;

  libusb_context *ctx = NULL;

  int attached = 0;

   result = libusb_init(&ctx);

  if (result == 0) {

  if (usb_trace_enabled)

  libusb_set_debug(ctx,255); // LIBUSB_LOG_LEVEL_DEBUG,
LIBUSB_LOG_LEVEL_WARNING

  ssize_t i = 0;

  int err = 0;

  ssize_t cnt = libusb_get_device_list(ctx, &list);

  if (cnt < 0){

    fprintf(stderr, "ERROR: no usb devices found\n" );

    error();

  }

   // find our device. Note we are using the brute force method rather

  // than open_device_with_vid_pid() because we need the device pointer

  // to look at the config descriptor.

  for(i = 0; i < cnt; i++){

    libusb_device *device = list[i];

    if( is_correctdev(device) ){

      found = device;

      break;

    }

  }

  if(!found){

    fprintf(stderr, "ERROR: could not find device\n");

    error();

  } else {

    if (verbose_flag) printf( "found usb-dev!\n" );

  }

  struct libusb_config_descriptor *p_cfgd;

  /** Set the interface based on config desc value */

  /** Use interface 0 if we are HID only device */

  /** Use interface 1 if we are combo HID/SonaCom */

  result = libusb_get_active_config_descriptor(found, &p_cfgd);

  if (result < 0) {

    fprintf(stderr, "ERROR: could not get configuration descriptor: %d\n",
result);

    error();

  } else {

    if (verbose_flag) printf("Attaching to interface %d...\n",
p_cfgd->bNumInterfaces-1);

  }

  INTERFACE_NUMBER = p_cfgd->bNumInterfaces-1;

  libusb_free_config_descriptor(p_cfgd);

  /** open device and get its handle */

  err = libusb_open(found, &devh);

  if (err){

    fprintf(stderr, "ERROR: Unable to open usb device\n");

    error();

  }

  /** Free Device List */

  libusb_free_device_list(list, 1 /* unref devices */);

  /** detach kernel: NEEDED??? */

  if ( libusb_kernel_driver_active(devh,0) ){

    libusb_detach_kernel_driver(devh,0);

    attached = 1;

  } else if (verbose_flag) printf("Device free from kernel\n");

    if (devh != NULL) {

      /** now attempt to attach to interface */

      result = libusb_claim_interface(devh, INTERFACE_NUMBER);

      if (result >= 0) {

        device_ready = 1;

      } else {

        fprintf(stderr, "libusb_claim_interface error %d\n", result);

      }

    } else {

      fprintf(stderr, "Unable to find the device.\n");

    }

  } else {

    fprintf(stderr, "Unable to initialize libusb.\n");

    return(1);

  }

   return 0;

}


libusb: debug [libusb_get_device_list]
libusb: debug [windows_get_device_list] allocating new device for session
[2A2]
libusb: debug [windows_get_device_list] allocating new device for session
[283]
libusb: warning [windows_get_device_list] could not retrieve port number
for device '\\.\ROOT#INTEL_UOIP_BUS_DRIVER#0000', skipping: [13] The data
is invalid.
libusb: debug [get_api_type] driver(s): usbhub
libusb: debug [get_api_type] matched driver name against HUB API API
libusb: debug [windows_get_device_list] allocating new device for session
[31]
libusb: debug [get_api_type] driver(s): usbhub
libusb: debug [get_api_type] matched driver name against HUB API API
libusb: debug [windows_get_device_list] allocating new device for session
[324]
libusb: debug [get_api_type] driver(s): USBHUB3
libusb: debug [get_api_type] matched driver name against HUB API API
libusb: debug [windows_get_device_list] allocating new device for session
[3F4]
libusb: debug [windows_get_device_list] allocating new device for session
[2B6]
libusb: debug [init_device] got bus number from ancestor #3
libusb: debug [init_device] found 1 configurations (active conf: 1)
libusb: debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 71 bytes)
libusb: debug [init_device] (bus: 2, addr: 16, depth: 1, port: 2):
'\\.\USB#VID_2848&PID_8003&MI_00#6&19BCFBB8&0&0000'
libusb: debug [windows_get_device_list] extra GUID:
{856BB44E-43CD-4F1C-9500-346AF6F6CF2C}
libusb: debug [windows_get_device_list] allocating new device for session
[8C]
libusb: debug [init_device] found 1 configurations (active conf: 1)
libusb: debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 34 bytes)
libusb: debug [init_device] (bus: 2, addr: 4, depth: 1, port: 3):
'\\.\USB#VID_2848&PID_8003&MI_01#6&19BCFBB8&0&0001'
libusb: debug [windows_get_device_list] allocating new device for session
[D3]
libusb: debug [init_device] found 1 configurations (active conf: 1)
libusb: debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 71 bytes)
libusb: debug [init_device] (bus: 2, addr: 16, depth: 1, port: 2):
'\\.\USB#VID_2848&PID_8003#BETA'
libusb: debug [windows_get_device_list] found existing device for session
[31] (0.0)
libusb: debug [init_device] got bus number from ancestor #2
libusb: debug [init_device] found 1 configurations (active conf: 1)
libusb: debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 25 bytes)
libusb: debug [init_device] (bus: 1, addr: 2, depth: 1, port: 1):
'\\.\USB#VID_8087&PID_8000#5&2864ADB3&1&1'
libusb: debug [windows_get_device_list] allocating new device for session
[1EB]
libusb: debug [init_device] found 1 configurations (active conf: 1)
libusb: debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 796 bytes)
libusb: debug [init_device] (bus: 2, addr: 3, depth: 1, port: 5):
'\\.\USB#VID_04F2&PID_B3BE&MI_00#6&2D1249EA&0&0000'
libusb: debug [windows_get_device_list] allocating new device for session
[256]
libusb: debug [init_device] found 1 configurations (active conf: 1)
libusb: debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 177 bytes)
libusb: debug [init_device] (bus: 2, addr: 2, depth: 1, port: 6):
'\\.\USB#VID_8087&PID_07DC#5&1B292275&0&6'
libusb: debug [windows_get_device_list] allocating new device for session
[2B0]
libusb: debug [init_device] found 1 configurations (active conf: 1)
libusb: debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 34 bytes)
libusb: debug [init_device] (bus: 2, addr: 4, depth: 1, port: 3):
'\\.\USB#VID_0EEF&PID_A108#5&1B292275&0&3'
libusb: debug [windows_get_device_list] allocating new device for session
[231]
libusb: debug [init_device] found 1 configurations (active conf: 1)
libusb: debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 796 bytes)
libusb: debug [init_device] (bus: 2, addr: 3, depth: 1, port: 5):
'\\.\USB#VID_04F2&PID_B3BE#0X0001'
libusb: debug [windows_get_device_list] found existing device for session
[324] (1.0)
libusb: debug [init_device] (bus: 1, addr: 1, depth: 0, port: 0):
'\\.\USB#ROOT_HUB20#4&36E14FC0&0'
libusb: debug [discovered_devs_append] need to increase capacity
libusb: debug [windows_get_device_list] allocating new device for session
[3CF]
libusb: debug [init_device] found 1 configurations (active conf: 1)
libusb: debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 39 bytes)
libusb: debug [init_device] (bus: 2, addr: 7, depth: 1, port: 1):
'\\.\USB#VID_0B95&PID_7720#11309D'
libusb: debug [windows_get_device_list] found existing device for session
[3F4] (2.0)
libusb: debug [init_device] (bus: 2, addr: 1, depth: 0, port: 0):
'\\.\USB#ROOT_HUB30#4&1881582C&0&0'
libusb: debug [get_api_type] driver(s): HidUsb
libusb: debug [get_api_type] matched driver name against HID API API
libusb: debug [windows_get_device_list] found existing device for session
[2B0] (2.4)
libusb: debug [get_api_type] driver(s): AX88772
libusb: debug [windows_get_device_list] found existing device for session
[3CF] (2.7)
libusb: debug [get_api_type] driver(s): usbccgp
libusb: debug [get_api_type] matched driver name against Composite API API
libusb: debug [windows_get_device_list] found existing device for session
[D3] (2.16)
libusb: debug [get_api_type] driver(s): BTHUSB
libusb: debug [get_api_type] lower filter driver(s): ibtusb;btmhsf
libusb: debug [windows_get_device_list] found existing device for session
[256] (2.2)
libusb: debug [get_api_type] driver(s): usbccgp
libusb: debug [get_api_type] matched driver name against Composite API API
libusb: debug [windows_get_device_list] found existing device for session
[231] (2.3)
libusb: debug [windows_get_device_list] setting HID interface for [2B0]:
libusb: debug [set_hid_interface] interface[0] =
\\.\HID#VID_0EEF&PID_A108&COL02#6&2F153F61&0&0001#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb: debug [windows_get_device_list] setting HID interface for [2B0]:
libusb: debug [set_hid_interface] interface[1] =
\\.\HID#VID_0EEF&PID_A108&COL03#6&2F153F61&0&0002#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb: debug [get_api_type] driver(s): WinUSB
libusb: debug [get_api_type] matched driver name against WinUSB API
libusb: debug [windows_get_device_list] setting composite interface for
[D3]:
libusb: debug [set_composite_interface] interface[1] =
\\.\USB#VID_2848&PID_8003&MI_01#6&19BCFBB8&0&0001#{856BB44E-43CD-4F1C-9500-346AF6F6CF2C}
libusb: debug [libusb_get_device_descriptor]
found usb-dev!
Attaching to interface 1...
libusb: debug [libusb_open] open 2.16

libusb: debug [unsupported_open] unsupported API call for 'open'
(unrecognized device driver)
libusb: debug [libusb_open] open 2.16 returns -12
ERROR: Unable to open usb device

l

Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)

[Pete B. <not...@gi...>]

Hi Chris,

No objection from me. ;)

You've been around our lists long enough, have been doing plenty of good work already, and crucially, you indicate that you have some time for it, so if you want the Windows maintainer job, since I'm pretty sure other maintainers will feel the same way I do, consider it yours!

I have now added you to the list of github maintainers for the project, and if you send one of us your SourceForge username, we can also add you to the project there (which is required for file uploads, etc.)

I should also point out that, I'm not planning to drop off the libusb map altogether, so I'll continue to try to help where I can (feel free to drop me an e-mail anytime).
Of course, you have my thanks for volunteering to take the Windows maintenance over!

Regards,

/Pete

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/9#issuecomment-48125032

Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)

[user83 <not...@gi...>]

What is the current state of hotplug/unplug support on windows? Is there any idea when it might be moved into the main branch (or whatever its called)? I am not familiar with the libusb code base, but if there is anything I could do to help (testing or whatever) it would be worth me putting a few days into this to get it working soon. Thanks

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/9#issuecomment-47836830

Re: [Libusbx-devel] bulk transfer error centos 6.5 (32-bit) on VirtualBox running on Windows 7 (64-bit)

[Kustaa N. <Kus...@pl...>]

Well Igor,

Tim put it a bit more bluntly than I perhaps would, I actually
refrained from making a comment ... but your post came across
as Linux evangelism so I'm not surprised that it provoked a
comment... you kind of asked for it.

You may not agree with what Tim wrote but you might still
take away from this that if your users are already using
Windows then using a virtual machine with linux, especially
when you are having problem clearly related to it seems
quite the wrong way to go about it.

And for the record I agree with most what Tim wrote about
Windows though I dislike Windows.

br Kusti


On 24/06/2014 21:13, "Igor Furlan" <igo...@gm...> wrote:

>wow   this was a hammer .... thanks for explaining it in clear
>profound words   I will keep it in mind  before write another sentence
>to the libusb-devel list.
>
>Thanks and have a nice day
>
>Igor
>
>
>On Tue, Jun 24, 2014 at 9:42 AM, Tim Roberts <ti...@pr...> wrote:
>> Igor Furlan wrote:
>>> On Mon, Jun 23, 2014 at 10:50 AM, Tim Roberts <ti...@pr...> wrote:
>>>> One of the advantages of libusb is that it crosses platforms.  Why
>>>>don't you run your code on Windows?
>>> Yes I could,,, but I wrote already few other utilities on LINUX
>>> (mostly GPIB related). I would like to continue on Linux. On top of
>>> that, licensing is free, no virues,  upgrading linux require just a
>>> recompile of my utilities, stability, reliability, abundance of
>>> programming/scripting tools   so, the users can use my utilities
>>> within any programming environment they are comfortable with. Like
>>> octave, shells,c, C++, Ruby, Perl, Pascal adn as a command line.
>>
>> OK, but you are intentionally overlooking the very important point that
>> YOUR USERS ARE ALREADY RUNNING WINDOWS.  You said this yourself.  They
>> already have licenses.  They already have virus checkers.  They already
>> know how to launch programs and interact.  They do not know Octave,
>> bash, Ruby, Perl, or Pascal.  You are asking them to run an additional
>> rather intrusive tool (VirtualBox) so they can run an entirely
>> unfamiliar environment just so you can feel religiously pure in your
>> development.
>>
>> Your upgrade argument is also silly.  An upgrade of Windows doesn't
>> require ANY recompiling of your tools and utilities.  The old binaries
>> just keep on working.  Microsoft has spent a vast fortune to ensure that
>> the Fortune 100 companies don't have to do any work on their
>> line-of-business tools to slip in an operating system upgrade.  Linux
>> developers, on the other hand, tend to favor purity over compatibility.
>>
>>
>>> Working remotely is a plus...  etc ..    Stuff I wrote in 2002/03 in
>>> my former company is still in use today, 12 years later. It was
>>> written for RedHat 8 2012 and just recompiled on CentOS 6.
>>
>> You're just making stuff up that doesn't have any basis in fact.  The
>> Windows remote access tools are just as good or better than the remote
>> access tools on Linux.  I'm still running Windows tools that I wrote and
>> last compiled in 1995.  Now that I'm running a 64-bit Windows, my
>> 25-year-old 16-bit tools no longer run, but I've known that was coming
>> for 10 years.
>>
>> It's interesting that you tried to use backwards compatibility as an
>> argument.  As a driver writer, I know that Windows has the best
>> backwards compatibility behavior of ANY of the major operating systems.
>> The video capture driver BINARIES that I wrote for Windows 98SE way back
>> in the 20th Century still run in Windows 8.  With a Linux kernel driver,
>> you often don't even get SOURCE compatibility between version x.y.z and
>> x.y.z+1.
>>
>> --
>> Tim Roberts, ti...@pr...
>> Providenza & Boekelheide, Inc.
>>
>>
>>
>>-------------------------------------------------------------------------
>>-----
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community
>>Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> libusbx-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
>
>
>--
>"You can't run an economy where the financial sector is making 40
>percent of the profits."
>
>
>        former Fed Chairman Paul Volcker 2009
>
>--------------------------------------------------------------------------
>----
>Open source business process management suite built on Java and Eclipse
>Turn processes into business applications with Bonita BPM Community
>Edition
>Quickly connect people, data, and systems into organized workflows
>Winner of BOSSIE, CODIE, OW2 and Gartner awards
>http://p.sf.net/sfu/Bonitasoft
>_______________________________________________
>libusbx-devel mailing list
>lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>


--
Kustaa Nyholm
Research Manager, Software
Research and Technology Division
PLANMECA OY
Asentajankatu 6
00880 HELSINKI
FINLAND

Please note our new telephone and fax numbers!
Tel: +358 20 7795 572 (direct)
Fax: +358 20 7795 676
GSM: +358 40 580 5193
e-mail: kus...@pl...






This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general.