Mohamed HAMZAOUI wrote:
> Is this a bug on the libusb/WinUsb or a limitation ?
Yes, I consider it a bug. Others might not.
//Peter
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access P
Peter Stuge wrote:
> Are there considerations (timing? something else?)
> related to asking Windows for memory as needed
Pete Batard wrote:
> Adding and testing array reallocation code is a PITA
> and development time is always super-limited
Thanks for the clarificatio
Pete Batard wrote:
> We do have a maximum limit on the number of (fake) fds
Why is that?
Are there considerations (timing? something else?) related to asking
Windows for memory as needed vs. using the current fixed size internal
array?
Thanks
//Peter
--
Arne Pagel wrote:
> As far as I understood libusb_get_config_descriptor gives my just
> cached values, can I force this function to perform an actual read
> from the Hardware?
No, but libusb_get_descriptor() will do a hardware access.
char buf[64];
libusb_get_descriptor(dev, LIBUSB_DT_CONFIG, 0x0
therau2000 wrote:
> > > libusb-1.0.dll is getting loaded by the interface class with the
> > > following command:
> > > MyLib libUSB = (MyLib) Native.loadLibrary("usb-1.0", MyLib.class);
> >
> > I don't even know what programming language that is? :\
>
> Fair enough. It is Java.
Ok. I googled:
therau2000 wrote:
> libusb-1.0.dll is getting loaded by the interface class with the
> following command:
> MyLib libUSB = (MyLib) Native.loadLibrary("usb-1.0", MyLib.class);
I don't even know what programming language that is? :\
> I need to unload libusb-1.0.dll to load another one.
>
> Quest
David Grant wrote:
> Rebooting is necessary for the "add user to group" change to take effect.
Once the user has been added to the group, it's very easy to "upgrade"
a running shell to use the new gid:
exec su "${USER}"
(What it does is of course to *replace* the current shell with a new
shell,
Pete Batard wrote:
> > I don't believe there were suggestions in any direction so far, but
> > I think using more of HIDAPI in libusbx would be a logical extension.
>
> Considering that libusbx is the lower level library here, theoretically,
> the most logical thing would be for HIDAPI to rely on
Stefano Di Martino wrote:
> What now? My program has to run under windows.
If you want to communicate with the HID class interface then I
suggest to try out HIDAPI.
HIDAPI was created specifically to abstract OS-native HID class APIs
on Linux, Windows, and Mac OS X.
While the Windows-specific HI
therau2000 wrote:
> > > In that case, will you please add "SCSI Pass Through" capability
> > > to libusbx?
> >
> > I won't, but maybe someone else will.
>
> Sorry, I thought you were making all decisions regarding where
> libusbx is going...
Pete Batard might tell you that I have no authority in
therau2000 wrote:
> > > You need to fork libusbx and create your own SCSI Pass Through
> > > backend by yourself if you really want to use libusbx.
> >
> > On the other hand libusbx already does this for HID class, so I
> > don't see why mass storage would be less worthy.
>
> In that case, will y
Xiaofan Chen wrote:
> You need to fork libusbx and create your own SCSI Pass Through
> backend by yourself if you really want to use libusbx.
On the other hand libusbx already does this for HID class, so I don't
see why mass storage would be less worthy.
therau2000 wrote:
> Before I tried to use
Alan Stern wrote:
> > I still think the storage subsystem has your answer.
>
> Speaking as someone who knows practically nothing about the various
> APIs in Windows, the impression I get is that the "competing program"
> is using a "raw SCSI" interface.
Right, I think so too.
> Does Windows pro
therau2000 wrote:
> > > 2-More intensive testing showed
> >
> > What testing?
>
> My own testing; who else's?
Of course, but how did you do it?
> > Let's try another approach: Tell us everything you know about the
> > device, and show some kind of capture of the non-storage communication.
>
>
therau2000 wrote:
> > > There is visibly something similar to Linux's "detach_kernel_driver"
> >
> > How did you determine that?
>
> 2-More intensive testing showed
What testing?
> > > 1-how can we detach/re-attach the default USBSTOR driver under Windows?
> > > 2-how can we load and attach li
therau2000 wrote:
> There is visibly something similar to Linux's "detach_kernel_driver"
> followed by "claim_interface" followed by lets-do-business followed by a
> "release_interface" followed by a "re-attach_kernel_driver" which then
> resumes normal removable drive operations.
How did you dete
Tim Roberts wrote:
> You can write to the device's control endpoint
> without claiming an interface at all.
I'm not sure this is true with WinUSB on Windows.
//Peter
--
Everyone hates slow websites. So do we.
Make your
g...@novadsp.com wrote:
> Interfaces: 2
..
> Interface Number: 0
> Number of endpoints: 2
..
> Interface Number: 1
> Number of endpoints: 0
>
> What I don't get is how to write to the second interface.
>
> Using anything other than an index of 1 for libusb_claim_interface()
> returns LIBUSB_ERRO
john smith wrote:
> Regarding your questions "Who is going to reap the completed URB?"
> I do have a seperated thread (LoopEvent), in a loop,
> call libusb_handle_events_timeout_completed every 100ms.
Why are you using such a short timeout? It generates overhead.
> But I got another "performance
g...@novadsp.com wrote:
> OK - the link provided by the OP also has an invalid SSL cert ...
The cert is valid, it's just that CAcert who has issued it isn't
included in the long list of CA:s trusted by the web browser.
You can add the CAcert key easily:
http://www.cacert.org/certs/class3.crt
If
Sean McBride wrote:
> >vs what is currently needed by tarball consumers
> >
> >- install Xcode
>
> Which you could reduce to zero steps if you provided binaries.
Absolutely! I'm all for providing binaries. What's the good method
for OS X? Is a .dmg suitable also for a library?
> >CMake unfortun
Sean McBride wrote:
> >Homebrew [1] is a very nice tools for installing external tools on
> >Mac OS X.
> >$ brew install libtool
>
> On Mac at least, that's now 3 dependencies:
> - install Xcode
> - install homebrew
> - 'brew install' libtool
>
> vs
>
> - install Xcode
> - install CMake
vs
Sean McBride wrote:
> >> Other than finding and installing 'libtoolize', is there another
> >> way to build?
> >
> >I guess not. Feel free to contribute something.
>
> Where can I find Vitali's CMake support? I'd be interested to know
> what state it's in...
https://github.com/vlovich/libusb/tre
Sean McBride wrote:
> >Note that autotools are requited _only_ for people using the GIT
> >version.
>
> What is the difference? What is included with the "released"
> version that is not included with git, and why?
The difference in this case is that the autotools have been run by
whoever create
g...@novadsp.com wrote:
> All I really need to do is send a few bytes of configuration data over
> the control endpoint but can see no way of doing that with the Windows
> stack in the way ..
Use bDeviceClass 0xff (vendor specific) and install the winusb kernel
driver using libwdi in any part of
Sean McBride wrote:
> I just forked libusbx on github and tried to build it. README.git
> says "run either ./autogen.sh or ./bootstrap.sh" but both result in:
>
> libtoolize or glibtoolize was not found! Please install libtool.
>
> autotools used to be part of Xcode, but was removed as of 4.3 (M
Chuck Cook wrote:
> From my point of view. I would like to see libusb-1.0 go through
> another iteration or two.
Sounds like a great opportunity to get more involved. Go for it!
> tests with baseline devices which exercise all functions of every API
If you've been using the API then this coul
Lionel Debroux wrote:
> I guess I need to be educated: how "not constructive" is suggesting
> that someone should spend time on activities more productive than
> duplicating work already done by someone else in another project ?
Who said anything about duplicating work? That would be a waste of
ti
Lionel Debroux wrote:
> The maintainer of libusb has proved, for two years, to be a roadblock on
> the path of advancing the state of libusb and on making life easier for
> users.
I think it would be fair of you to look closely at the repository
history before we discuss if and how I advanced the
Hi Bob,
Bob Lapique wrote:
> On Linux, it is pretty straightforward to detect device connection /
> disconnection with libusb_set_pollfd_notifiers().
This is unfortunately not very portable use of the libusb-1.0 API,
in particular it's not portable to Windows, because Windows doesn't
use file de
Bob Lapique wrote:
> What I want to do is to communicate with a home made board, based on a
> Microchip PIC microcontroller (PIC18 or PIC32), with interrupt
> transfers. I don't want anything special, just send and receive packets
> to trigger measurements and get the results. But at the moment,
Hi Bob,
Bob Lapique wrote:
> the right place to seek help on basic Libusbx usage...
Sure, if you find no other resource to explain what you want to know.
> If not, I'd be very pleased if someone could redirect me to some place
> where the difference between the Linux and Windows implementation
Pete Batard wrote:
> > I don't understand why the fd integer is allocated using _open()
> > instead of allocating it in the library using a simple counter or so.
>
> Because "using a simple counter or so" requires more lines of codes to
> ensure we are emulating fd allocation than a one line call
Pete Batard wrote:
> the error basically comes
> from trying the following: _open("NUL", _O_WRONLY);
I don't understand why the fd integer is allocated using _open()
instead of allocating it in the library using a simple counter or so.
It seems that the fd is just a placeholder; no actual IO goe
I don't know how wise it is to mix the two different namespaces.
//Peter
--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite
d0447050 Mon Sep 17 00:00:00 2001
From: Peter Stuge
Date: Wed, 22 Aug 2012 01:32:10 -0700
Subject: [PATCH] io.c: Handle >= 1 second transfer timeout in
libusb_submit_transfer()
---
libusb/io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libusb/io.c b/libusb/io.c
Pete Batard wrote:
> Now, if part of your concern has to do with avoiding user intervention
> with regards to manually installing a driver, WCID could help [1] since
> WinUSB/WCID devices
Just a small note that the term Microsoft uses is "WinUSB Device".
That can help for finding their info abou
Kevyn-Alexandre Paré wrote:
> I at least need to send 2 bytes to the FPGA to receive back a NAK
> in case of a bad 2 first bytes. In case of a proper trame this will
> send a ACK or data packet.
You can simplify your protocol significantly since USB transfers,
aside from isochronous, are a reliabl
David Grant wrote:
> mass storage support?
I guess you already have the following in mind?
http://libusb.org/wiki/FAQ#CanIuselibusbtoopenafileonaUSBstoragedevice
//Peter
--
Live Security Virtual Conference
Exclusive li
g...@novadsp.com wrote:
> Hello Pete
(Note that Pete is another guy. :)
> >> ? err, no. My device might well start to write back down the pipe as
> >> soon as it has been configured.
> >
> > That would be a violation of the USB protocol.
>
> My bad. Sloppy phrasing. Configured as in 'told what
g...@novadsp.com wrote:
> > No good since there can be no data from device until you initiate a
> > transfer.
>
> ? err, no. My device might well start to write back down the pipe as
> soon as it has been configured.
That would be a violation of the USB protocol.
What device controller are you
g...@novadsp.com wrote:
> Once I have opened a device using LibUsbX, is there a
> synchronization handle I can pend on whilst waiting for the
> peripheral device to write back to the host?
The device is not allowed to transmit to the host before your
application requests data.
> // open device e
Pete Batard wrote:
> I have now pushed a patch that adds libusb0.sys and libusbK.sys
> support there, for testing.
I look forward to some testing! Even if it comes at the cost of the
libusbK DLL it's still very nice that libusb-1.0 code can be used
with the libusb-win32 driver.
> To fetch the br
Andrea Oliveri wrote:
> how can i understand
Suggest show the code again, and since you are now getting to actual
data transfer please also include debug output.
https://libusb.org/wiki/debug mentions how to do this for libusb, but
the instructions work also for libusbx if you adjust the URL.
/
Hans de Goede wrote:
> > The only way to fix this for certain is to add an atomic
> > detach-and-claim call to the kernel. I don't know if this is
> > worth it, though.
>
> Having spend some time thinking about this, I believe it is worth
> it, both to fix this race, as well as to fix the
> detac
Andrea Oliveri wrote:
> I run the same code under Fedora 17 and it's OK.
I think you get a warning in the kernel log.
> When the application try to read data from the device under windows
> i receive this error message:
>
> libusbx: error [libusb_submit_bulk_transfer] unable to match endpoint t
Hans de Goede wrote:
> If the usbfs driver is found LIBUSB_ERROR_NOT_FOUND will be
> returned to indicate no driver was detached.
What is the situation like for other platforms besides Linux, and
does the change also require documentation?
//Peter
---
Hans de Goede wrote:
> This patch fixes libusb_detach_kernel_driver to only detach "real"
> kernel drivers and not the special usbfs driver
Ignoring the race for now? What's the situation of kernel support to
make the operations race free? It has always been the plan of course.
//Peter
Luiz Andrade wrote:
> do you know if it's possible to use garmin sdk on linux?
Unlikely.
> Can you give me some advice to make this work on linux to?
>
> Maybe I can make my application use some gps program like gpsd or gpsbabel,
> making a frontend for the command line interface. Is that a goo
Kevyn-Alexandre Paré wrote:
> Here's the code and output of my test. I'm trying to understand
> what's going wrong! I mean that I'm expecting the callback function
> "cb_xfr" from my bulk transfer to be called after
> libusb_submit_transfer is called. I'm communicating to a FPGA
> through a Cypress
Pete Batard wrote:
> Where did the issue become trying to convince Yves that using git
> (or another VCS for that matter) was better for him?
I don't know how you came up with the idea that I tried to do that.
Fortunately it didn't seem like Yves interpreted what I wrote like
you did.
Communicat
Pete Batard wrote:
> you're going to earn yourself a ban.
That's confusing, but I guess you'll do as you like.
> > but working
> > with git does require more of you. I think that's a good thing
>
> Please keep this bullshit about how git is going to save the world
I didn't write as verbosely a
Yves Arrouye wrote:
> I was a bit surprised that the default installation obtained by cloning
> (using git clone on the command line)
> git://github.com/libusbx/libusbx.gitdid not include a configure
configure & co are generated and included in release tarballs. Since
they are generated files they
John Chen wrote:
> Would you please show me how did you get bmRequestType to value 0xC2.
Please see the USB 2.0 spec 9.3.1 bmRequestType Table 9-2 page 248.
http://www.usb.org/developers/docs/usb_20_10.zip
//Peter
-
Markus wrote:
> I can't see a generally reliable way to get my hands on the HC
> information while at the same time, being able to infer which
> devices are connected (by means of libusb_get_bus_number() result).
> Do I overlook something here?
Well the HC is not a USB device, so it does not f
John Chen wrote:
> I have not touch anything like device driver before, do you have
> any good book to recommend?
One good resource is the USB 2.0 specification. Study chapters 5, 8,
and 9.
http://www.usb.org/developers/docs/usb_20_10.zip
//Peter
---
Pete Batard wrote:
> > Is it true also for Windows?
>
> The current code doesn't attempt to cache any descriptors for root hubs,
So the Windows USB stack does not provide root hub descriptors?
(If so that's perfectly fine, I'm just trying to understand how
Windows exposes the root hubs.)
> St
Pete Batard wrote:
> > but it doesn't prevent you from retrieving root-hub descriptors.
> > The descriptors simply come from the OS's driver rather than from
> > an external device.
>
> That makes sense.
Is it true also for Windows?
//Peter
-
Markus wrote:
> my question is slightly off-topic since its affects a property of
> USB that's presumably standardized. Nevertheless, I'm unable to
> find any definite information on this:
>
> Is it correct that the root hub of a host controller has always
> address 255 on the given USB bus?
No,
John Chen wrote:
> I am using libusb-1.0.9, under windows 7
Just a note that the debug log you sent is from libusbx, so check
which DLL gets used if you intended something else.
> I am also able to get serial # from one of our legacy app (written
> with windows API)
Note that retrieving a strin
Pete Batard wrote:
> I find this as both very rude and damaging, as, seeing that you are not
> endorsed as a moderator here, yet pretend to be entitled to act like
> one, it does end up sending mixed messages.
I tried to make clear that I have no entitlement in libusbx beyond
freedom of speech.
Hi Toby,
As Pete likes to point out I have no authority in the libusbx
project, so as far as libusbx is concerned I think the best
might be if you could pretend that I had never posted this
feedback on the libusbx list.
Please consider my feedback to be in the context of the libusb
project, where
r timeout error.
I think the smaller timeout error and most importantly having the
user-specified timeout be a lower bound rather than an upper bound
is preferable.
//Peter
>From ca77a1a541aaa3b2f0cbc4ea03e1eeca3dd5aa5a Mon Sep 17 00:00:00 2001
From: Peter Stuge
Date: Tue, 10 Jul 2012 16:54:16
s fixed in libusb yesterday.
I'm attaching a patch that applies on top of libusbx.git, and for
convenience it is also available via
git fetch git://git.libusb.org/libusb-stuge.git for_libusbx/timerfd_fix && \
git cherry-pick FETCH_HEAD
//Peter
>From 26ff10182876b67cc6035d4db7f2732dd3
Kevyn-Alexandre Paré wrote:
> > Data never becomes available.
> > The application asks the device to send data, when the application
> > knows that data is supposed to be available in the device.
>
> Agree, in my case I send data to an FPGA and I'm always expecting to
> receive data from it. The a
Kevyn-Alexandre Paré wrote:
> 3- In the callback I need to know what the FD is referring to and
> take action, ex: data is ready to be read for the FD of bulk
> transfer.
This is a misunderstanding of USB. Data never becomes available.
The application asks the device to send data, when the applica
Timotei Dolean wrote:
> I'll look in the meantime into the alternative to the
> select()-based method, maybe that will get it working.
Yes, it can't work before then.
//Peter
--
Live Security Virtual Conference
Exclusiv
Hi Timotei,
Timotei Dolean wrote:
> Is there something I'm missing, or there is no way to make libusb
> work correctly on windows in my scenario?
Both libusb and libusbx will work if you change the usbmuxd event
handling from a select()-based approach to having a dedicated thread
which calls libu
Pete Batard wrote:
> the API is really only one part of it
In a library the API is almost the only thing that matters. We've
long ago established that the libusb-1.0 API doesn't fit Windows and
that the Windows code has to jump through hoops because of that.
> balance API requirements with resou
Peter Stuge wrote:
> Is there a reason why we would ever not want to set AUTO_CLEAR_STALL?
>
> It's done unconditionally now, which seems to be the right way to go
> so that the 31 error happens for one less reason.
On the other hand, do other backends automatically clear s
Orin Eman wrote:
> > > > What does GetLastError() return in the relevant cases after the
> > > > WinUsb functions return FALSE?
>
> FWIW, WinUsb_ReadPipe() will return 22 immediately if the device is
> disconnected, BUT a pending overlapped WinUsb_ReadPipe() may* complete
> with error 31 - ERROR_G
even if the same thing happens in
> > both cases. (It makes sense for the same thing to happen.)
>
> I was referring to the following:
>
> On 2012.05.17 14:27, Peter Stuge wrote:
> > If a device becomes unavailable (which can happen without this patch
> > too of
Johannes Stezenbach wrote:
> Doesn't Windows (WinUSB to be precise) return an error code
> indicating the device was unplugged for the submitted transfers?
Can you provide a debug log? I assume you check for submit errors,
and I'm interested in seeing what happens to those later 13.
Thanks!
//P
Pete Batard wrote:
> > Hotplug isn't there yet, and Liam's problem is because the Windows
> > backend doesn't currently implement what the libusb-1.0 API currently
> > offers. Without hotplug. This is a bug in the Windows backend.
>
> Implementing this will require some form of hotplug handling in
philip.jos...@microchip.com wrote:
> devices that do not have such descriptors will apparently still
> require an INF file for install purposes.
Yes, that is true. At least the problem is going away in the future.
> Having a single API and "single library" across platforms would
> still provide
Hi Philip,
philip.jos...@microchip.com wrote:
> the incentive to uncomplicated the user's experience has driven
> many implementers to HID on Windows.
Yes, this is easy to understand. I think by far the best solution to
communicate with HID class devices "manually" is to use HIDAPI.
> Even with
Markus wrote:
> I managed to bring the FX3 firmware upload into a working state now.
> Instead of making it a commandline tool on its own, I decided
> to diff it against xusb.c
I guess that the fx2load package would welcome a patch! :)
If you prefer to add an fx3load example to libusb instead th
Hotplug isn't there yet, and Liam's problem is because the Windows
backend doesn't currently implement what the libusb-1.0 API currently
offers. Without hotplug. This is a bug in the Windows backend.
> >> - is this an appropriate way to manage the process of closing my device?
> >
> > Yes, it is.
Xiaofan Chen wrote:
> > Bug report to dlltool (actually invalid as pointed by Kai).
> > http://sourceware.org/bugzilla/show_bug.cgi?id=14258
>
> On the other hand, Ruben disagreed with Kai and he
> thinks that the library name is optional.
This is not a subjective matter. MS is the authoritative
Nathan Hjelm wrote:
> As I said I will not add nor support IOHID access for libusb on OSX/Darwin
This special case HID class code which was removed from libusb long
ago and now added back into libusbx by Pete didn't belong in libusb
in the first place, and I think it will remain unique to libusbx.
g...@novadsp.com wrote:
> Assuming I need a user-mode interface to a custom USB Bulk class device:
>
> 1. Can I use Zadig to install a WinUSB driver for the VID/PID?
Yes, that's one of the things it is meant for. You can also use
libwdi in your own program, to do what zadig does, but in a more
au
Lars Kanis wrote:
> I maintain the libusb-1.0-binding for Ruby (
> https://github.com/larskanis/libusb ). The precompiled version for
> Windows is built from libusb-1.0.9 sources with 32 bit version of
> mingw-w64-2.0.1 and gcc-4.6.3 on Ubuntu 12.04. Recently I noticed two
> issues, I would like to
Sandor Otvos wrote:
> i need this string , to distinguish more identical devices
As I mentioned in the reply I just sent to your post to libusb-devel,
there's a commit in libusbx.git since yesterday which makes available
the location of the USB device on the USB bus, which you could use,
and which
Pete Batard wrote:
> On 2012.05.27 09:27, Peter Stuge wrote:
> > It would probably be simpler to do the same thing by moving the
> > setting of first to before the loglevel check within the logging
> > function.
>
> Except there's no guarantee that the logging f
Pete Batard wrote:
> It looks like trying to access 0xEE on Mac produces a pipe stall.
Doesn't that make sense actually, for devices which don't have that
string descriptor?
//Peter
--
Live Security Virtual Conference
E
Pete Batard wrote:
> 1. It sets the origin of the timestamps to the first libusb_init() call
> issued by the application. The idea is to avoid getting an arbitrary origin
> once we have toggleable logging, as it is currently set to the first debug
> message ever issued, which isn't something an
g...@novadsp.com wrote:
> Why on earth make WinUSB without isoch support.
I think Microsoft felt that C/B/I was good enough.
> > though we're planning to add drivers that support isoch in the
> > future.
>
> Has anyone started working on this?
Sure, and there is an implementation, but the impl
Yves Arrouye wrote:
> How can I do that?
No solution AFAIK.
> It does not help that the full command-line isn't displayed (how can I
> see that instead of the fake command lines here, by the way)...
make V=1
> rather not have to build twice and lipo everything together,
This does however wor
Hi Yves,
Yves Arrouye wrote:
> It seems to me that location ID is worth being part of the topology
> information, and offers a reliable way to identify a device on both
> the libusbx side of things and the native OS side too.
What about the portability of the information? I mean: with
platform-sp
g...@novadsp.com wrote:
> I've got a custom USB bulk device (Blackfin based with my own firmware
> for what it's worth).
Fun! Did you already verify the USB part of the firmware, or is this
part of what you are doing right now?
> I run xdev face:feed (our VID/PID) and all device info gets repor
Xiaofan Chen wrote:
> I think the warning message is a bit miss-leading. If libusbx found
> /, then it should probably warn against unrecognized device.
If Windows says that there is a 0:0 device when there is actually an
error, and if this case is indistinguishable from an OK device with
Xiaofan Chen wrote:
> >> ok pete i tryed it again,
> >> got a bit of a different message, but still failed.
>
> Also since you are using Cygwin which has its older libusb-1.0,
> you may want to remove the older libusb-1.0 cygwin package
I've helped Dan with this a bit. The ubertooth package and a
Uri Lublin wrote:
> >> Only if old backend api is UNSUPPORTED.
> > Hm. Shouldn't the check be done unconditionally - and for all
> > devices, ie. in every pass except perhaps HCD? Otherwise I think
> > the bug still bites when installing the previous driver after
> > unredirecting the device?
>
>
Uri Lublin wrote:
> Only if old backend api is UNSUPPORTED.
Hm. Shouldn't the check be done unconditionally - and for all
devices, ie. in every pass except perhaps HCD? Otherwise I think the
bug still bites when installing the previous driver after
unredirecting the device?
//Peter
Pete Batard wrote:
> if you want to dismiss the Windows backend as full of bugs
I never wrote that and I never hinted at that.
This email thread is about just one bug.
> fixing this is likely to be a waste of time when we could spend it
> on implementing the full hotplug.
..if you don't mind h
Pete Batard wrote:
> > The bug is that the Windows backend requires a libusb_device * to be
> > unref:ed before libusb_get_device_list() reports system changes,
> > while other backends do not have this limitation and it is documented
> > that libusb_get_device_list() does not have this limitation.
Pete Batard wrote:
> Right now, outside of not freeing the list (but in that case, expecting
> an enum list to auto-update itself if after it has been generated IS
> hotplug),
You seem to miss that the list is expected to be updated on call to
libusb_get_device_list() - noone has said anything a
Uri Lublin wrote:
> Maybe the problem can be solved in the application.
I think that would be a workaround.
> Likely I can unref it before driver installation, and find it again
> after the installation.
It seems racy and unneccessary to me.
//Peter
--
Pete Batard wrote:
> On 2012.05.14 18:44, Peter Stuge wrote:
> > I don't think that should be neccessary. If replacing the driver does
> > not lead to a new libusb_device * for the device then I think it is a
> > bug if the device must be destroyed before accurate state i
Pete Batard wrote:
> A device that cannot be opened should not be kept instantiated by
> libusbx outside of get_device_list-free_device_list, so maybe the
> only thing you miss is ensuring the device list is destroyed before
> you call on get_device_list again.
I don't think that should be necces
1 - 100 of 127 matches
Mail list logo
