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
On 2012.05.15 02:25, Peter Stuge wrote:
> and the Windows
> backend doesn't really deliver because of this bug and with a few
> others. (That difficult-to-spot enumeration bug, cross-thread
> cancellation, and who knows what else.)
Ah, the famous "who knows what else" as a diminutive argument for
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.
On 2012.05.15 00:54, Xiaofan Chen wrote:
> Nothing special to reproduce. You got 50% chance of segfaults running
> the same command again and again.
Yeah, I've actually been testing this, and I was able to reproduce it
against the benchmark device (haven't tested any other).
It seems all that's
On 2012.05.14 19:41, Peter Stuge wrote:
> 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
> libu
On 2012.05.14 19:30, Peter Stuge wrote:
>> .. hotplug ..
>
> 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(
On Mon, May 14, 2012 at 11:24 PM, Pete Batard wrote:
> On 2012.05.14 14:16, Xiaofan Chen wrote:
>> Somehow xusb now segfaults sometimes.
>
> It seems to segfault when retrieving the topological data on Mac, which
> of course explains why 1.0.11 is fine.
>
> [ 0.913785] [1307] libusbx: info [da
On 05/14/2012 03:12 PM, Pete Batard wrote:
I addressed this point already. It doesn't matter if you modify libusbx
or add an extra layer on top of it. The issue is you are replicating a
feature that libusbx is planning to provide, and that, as far as I could
see from my tests, unless somebody els
On 05/14/2012 01:41 AM, Pete Batard wrote:
> So, in summary, the issue is:
> - you have developed a custom solution/layer to add hotplug to libusbx,
> even as libusbx is going to officially implement the very same feature,
> internally, in a manner that is likely to be quite different from yours.
On 05/14/2012 06:22 PM, Pete Batard wrote:
> On 2012.05.14 16:48, Uri Lublin wrote:
>> The scenario I was looking at is:
>> libusb_get_device_list
>> device = go over the list of devices and find the one with
>> appropriate vid,pid
>> libusb_open(device)
>> if fa
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 is reported
> > by calls to
On 2012.05.14 18:26, philip.jos...@microchip.com wrote:
> We provide two basic interfaces in the above layer (speaking from a Java
> point of view): A provider interface and a device interface. The
> provider handles getting the device list and keeping it up to date and
> notifying any registered l
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 is reported
> by calls to _get_device_list().
Installi
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
When our app first comes up (actually the interface layer for our apps),
it uses libusb to get a list of devices that are currently on the bus.
The information in that list is placed in our own internal list,
filtered by the user's request to our interface layer (in that, all USB
devices, devices w
On 2012.05.14 16:48, Uri Lublin wrote:
> The scenario I was looking at is:
> libusb_get_device_list
> device = go over the list of devices and find the one with
> appropriate vid,pid
> libusb_open(device)
> if failed:
> install libusb device driver
>
On 05/10/2012 02:28 PM, Pete Batard wrote:
> On 2012.05.01 16:52, Uri Lublin wrote:
>> Only if old backend api is UNSUPPORTED.
>>
>> This happens when a libusb driver (e.g. WinUSB) is installed
>> after a device has been setup/discovered (with get_device_list).
>
> I'm currently testing this, so th
On 2012.05.14 14:16, Xiaofan Chen wrote:
> The leading ">" in">From" is automatically added by the mailing list
> so you can not stop it.
>
> But I am not so sure why your attachment also has the ">" before "From"
> which will cause "git am" to fail.
Looks like this means I won't be able to please
On Mon, May 14, 2012 at 8:24 PM, Xiaofan Chen wrote:
> On Mon, May 14, 2012 at 7:56 PM, Pete Batard wrote:
>> Moving on with the list of 1.0.12 items, the attached patch reinstates HID
>> support for Windows, as well as adds HID feature reports querying to xusb.
>
> Great. I should be able to giv
On Mon, May 14, 2012 at 7:50 PM, Pete Batard wrote:
> v2, that takes into account what was discussed previously (but still
> provides get_parent).
Seems to work fine under Windows.
The difference between the first run and the 2nd run is that
I add an old full-speed USB Hub in between the device
On Mon, May 14, 2012 at 9:19 PM, Xiaofan Chen wrote:
> On Mon, May 14, 2012 at 9:16 PM, Xiaofan Chen wrote:
>> Somehow xusb now segfaults sometimes.
>
> BTW, 1.0.11 release never segfaults.
The default xusb is actually a wrapper. So I rebuild xusb with static
library and then run gdb. Here is th
On Mon, May 14, 2012 at 9:16 PM, Xiaofan Chen wrote:
> Somehow xusb now segfaults sometimes.
BTW, 1.0.11 release never segfaults.
mymacmini:examples xiaofanc$ ./xusb -d 04d8:fa2e
Using libusbx v1.0.11.10499
Opening device...
[timestamp] [threadID] facility level [function call]
--
On Mon, May 14, 2012 at 7:50 PM, Pete Batard wrote:
> v2, that takes into account what was discussed previously (but still
> provides get_parent).
>
> >From 4ff57d754aed031b8b73e161e56064338b4bd06a Mon Sep 17 00:00:00 2001
One minor thing first.
The leading ">" in ">From" is automatically added b
On Mon, May 14, 2012 at 7:56 PM, Pete Batard wrote:
> Moving on with the list of 1.0.12 items, the attached patch reinstates HID
> support for Windows, as well as adds HID feature reports querying to xusb.
Great. I should be able to give this some tests, like Jan Axelson's
generic HID firmware an
On 2012.05.14 10:29, Hans de Goede wrote:
> Hi,
>
> On 05/14/2012 12:41 AM, Pete Batard wrote:
>> So, in summary, the issue is:
>> - you have developed a custom solution/layer to add hotplug to libusbx,
>> even as libusbx is going to officially implement the very same feature,
>> internally, in a m
Hi,
On 05/14/2012 01:56 PM, Pete Batard wrote:
> Moving on with the list of 1.0.12 items, the attached patch reinstates HID
> support for Windows, as well as adds HID feature reports querying to xusb.
I'm afraid I'm not familiar enough with this code to review the patch,
but thank you for your c
v2, that takes into account what was discussed previously (but still
provides get_parent).
Regards,
/Pete
>From 4ff57d754aed031b8b73e161e56064338b4bd06a Mon Sep 17 00:00:00 2001
From: Pete Batard
Date: Mon, 14 May 2012 11:44:00 +0100
Subject: [PATCH] All: Add parent and port topology calls
*
Hi,
On 05/14/2012 12:41 AM, Pete Batard wrote:
> So, in summary, the issue is:
> - you have developed a custom solution/layer to add hotplug to libusbx,
> even as libusbx is going to officially implement the very same feature,
> internally, in a manner that is likely to be quite different from you
31 matches
Mail list logo
