Xiaofan Chen | 1 Dec 02:07 2010
Picon

Re: libusb_get_device_list returns -4

On Wed, Dec 1, 2010 at 7:46 AM, Pete Batard <pbatard <at> gmail.com> wrote:

> whereas, for the problematic interface we go:
>
>  -> HID#VID_046D&PID_C52B&MI_01&COL04
>  -> {A3...12}\VID_046D&PID_C52B&REV_1201&MI_02 (parent)
>  -> USB\VID_046D&PID_C52B&MI_02 (grandparent)
>
> This seems to indicate that we are missing one more level to get to an
> ancestor that should be in our existing lists. Logitech sure know how to
> keep us entertained with their uncommon HID implementations...
>

I guess the extra level is due to the installed HID mini-filter which is
common for things from Logitech/Microsoft/etc to enhance the
inbox keyboard/mouse/gamepad/etc drivers. I think you may need to
expect more levels.

--

-- 
Xiaofan

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
Peter Stuge | 1 Dec 02:54 2010
Picon

Re: libusb_get_device_list returns -4

Pete Batard wrote:
> for the device that is successfully detected, we trace back
> ancestors as follows:
> 
>   -> HID#VID_046D&PID_C52B&MI_01&COL03
>   -> USB\VID_046D&PID_C52B&MI_01 (parent)
>   -> USB\VID_046D&PID_C52B (grandparent, which we can recognize)
> 
> whereas, for the problematic interface we go:
> 
>   -> HID#VID_046D&PID_C52B&MI_01&COL04
>   -> {A3...12}\VID_046D&PID_C52B&REV_1201&MI_02 (parent)
>   -> USB\VID_046D&PID_C52B&MI_02 (grandparent)
> 
> This seems to indicate that we are missing one more level to get to an 
> ancestor that should be in our existing lists. Logitech sure know how to 
> keep us entertained with their uncommon HID implementations...

Xiaofan Chen wrote:
> I think you may need to expect more levels.

I agree with Xiaofan. Shouldn't the code just recurse up or down
until it finds the/an end?

//Peter

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
(Continue reading)

Pete Batard | 1 Dec 11:31 2010
Picon

Re: libusb_get_device_list returns -4

On 2010.12.01 01:54, Peter Stuge wrote:
> Xiaofan Chen wrote:
>> I think you may need to expect more levels.
>
> I agree with Xiaofan. Shouldn't the code just recurse up or down
> until it finds the/an end?

Yeah, that's the conclusion I am coming to. My original assertion was 
that there would never be more than 2 levels, because I had never seen 
an HID device with more, so that's what I went with because it made for 
simpler code,

Regards,

/Pete

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
Pete Batard | 1 Dec 14:06 2010
Picon

Re: libusb_get_device_list returns -4

Should be fixed in pbr324. If you issue a git pull and recompile, you 
should have the updated version. Binary snapshots have also been updated.

Regards,

/Pete

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
Peter Stuge | 1 Dec 14:34 2010
Picon

Re: [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

François Revol wrote:
> > usbip

I don't know how good this is.

For another implementation of USB-over-IP you could look at Sun's
work with the SunRay thin clients. I believe some of it may be in
the OpenUSB codebase. (They forked libusb to make it work the way
they wanted.) I don't know how good that is, either.

> > On the client side using libusb looks alot more sensible than
> > requiring kernel modules.
..
> It's just one implementation of it, it should be possible to
> implement a subset of the features at least with libusb which
> should be enough for most devices (scanners/printers/mass storage).

Keep in mind that libusb can be used only with USB interfaces which
have the usbfs driver bound to them. (Or no driver at all, in which
case usbfs is transparently bound at libusb_claim_interface() time.)

This means that any kernel driver (like usb-storage) must be moved
out of the way. This can be done with libusb, but not portably. Given
sufficient permissions it works nicely and on the fly in Linux, but
Mac OS X needs manual work and a reboot, and Windows needs to create
a restore point. On Windows the libwdi library can be used to switch
drivers for USB interfaces. http://libusb.org/wiki/libwdi

I have been mulling over if libusb should actually take on the
significant task of USB kernel driver management, offering a portable
(Continue reading)

Phong Truong | 1 Dec 18:08 2010
Picon

Re: libusb_get_device_list returns -4

Thanks Pete!

On Wed, Dec 1, 2010 at 5:06 AM, Pete Batard <pbatard <at> gmail.com> wrote:
Should be fixed in pbr324. If you issue a git pull and recompile, you
should have the updated version. Binary snapshots have also been updated.

Regards,

/Pete

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
Pete Batard | 1 Dec 18:49 2010
Picon

Re: Large receive buffer size causes an error?

On 2010.11.22 05:59, Peter Stuge wrote:
> libusb-stuge.git is the current state of my working tree. That is
> rebased frequently, but I only expect one split in there for now,
> and a few commit message changes. If anyone wants to review these
> commits, even if they will still change a little further, please go
> for it! I'll take into account any and all comments in my further
> work.

libusb-stuge broke cygwin compilation.

Getting the following when running configure from autogen.sh:

...
checking for sys/time.h... yes
configure: creating ./config.status
.in'ig.status: error: cannot find input file: `

Yup, the last line is verbatim.

And I'm going to rant again, but was it really necessary to split the 
configure.ac changes into 9 commits? What good will come of going atomic 
with such single liners as "Quote AC_COMPILE_IFELSE() input" or "Trivial 
whitespace changes and reordering", *REALLY*?

IMO, a simple "configure.ac improvements" with bullet points detailing 
each improvements could do wonders, especially as configure.ac is far 
from being our bread and butter. If producing such commits has been 
taking time away from progressing on the actual official integration for 
1.0.9, maybe we need to review our approach...

Regards,

/Pete

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
Pete Batard | 1 Dec 19:31 2010
Picon

cygwin errors with latest libusb-stuge

On 2010.12.01 17:49, Pete Batard wrote:
> .in'ig.status: error: cannot find input file: `

Why, yes, it's the old "cygwin doesn't like multiple files to be 
provided on multiple lines - YOU HAVE BEEN WARNED!" issue [1].

Please don't reorganize the AC_CONFIG_FILES list. It doesn't work with 
multiple lines on cygwin [2], even if you quote each file as I have just 
tested.

And I for one would like to place my vote into delaying all cosmetic 
changes, like the above, until much later, and instead focus only on 
what is really needed for the 1.0.9 release.

Regards,

/Pete

PS: now configure works, but I'm getting the following, still in cygwin 
(NB: MinGW was OK).

make[2]: Entering directory `/cygdrive/d/libusb-pbatard/libusb'
   CC     libusb_1_0_la-core.lo
In file included from core.c:30:
libusbi.h:831: error: parse error before "nfds_t"
libusbi.h:831: warning: function declaration isn't a prototype
make[2]: *** [libusb_1_0_la-core.lo] Error 1

[1] http://git.libusb.org/?p=libwdi.git;a=blob;f=configure.ac#l238
[2] 
http://git.libusb.org/?p=libusb-stuge.git;a=commitdiff;h=ea9f79daa3aec3c0c9b53b8fbac90ac0d0d28d3f;hp=a4a00780a224efc2dca4f3168509b99a1364e8a7;js=1

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
Pete Batard | 1 Dec 20:15 2010
Picon

Re: cygwin errors with latest libusb-stuge

Peter,

Can you tell where [1] comes from, and if this was ever tested on cygwin?

If Windows specific patches like this one are being introduced without 
being properly tested (haven't tested MSVC, since we don't have the 
project files), this is going to be a major headache.

Or at least, please submit it as a proposal to the list so that I can 
try to test it. I'm only realizing now that you have added a lot of 
changes in your tree that were never publicly debated on the list. Even 
as one of the libusb maintainers, if you want to integrate some non 
trivial changes into official, please try to submit a patch on the 
mailing list for review.

I'm afraid keeping all of MinGW, MSVC and cygwin happy at the same time 
is almost never straightforward, no matter how simple the patch might 
look, so for now, I'd suggest we revert this change (if it ain't 
broke...), and spend time on the rest of the integration instead. If I 
have a chance, I'll see if I can pick up your patch, and fix it for my 
branch, so that you get it back when official catches up.

Regards,

/Pete

[1] 
http://git.libusb.org/?p=libusb-stuge.git;a=commitdiff;h=e01877bec72eddeb314e1caf4047ee424d18ce66;js=1

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
Segher Boessenkool | 1 Dec 20:32 2010

Re: Large receive buffer size causes an error?

>> libusb-stuge.git is the current state of my working tree. That is
>> rebased frequently, but I only expect one split in there for now,
>> and a few commit message changes. If anyone wants to review these
>> commits, even if they will still change a little further, please go
>> for it! I'll take into account any and all comments in my further
>> work.
>
> libusb-stuge broke cygwin compilation.
>
> Getting the following when running configure from autogen.sh:
>
> ...
> checking for sys/time.h... yes
> configure: creating ./config.status
> .in'ig.status: error: cannot find input file: `
>
> Yup, the last line is verbatim.

Wow, that's...  special?  What on earth is going on there!

> And I'm going to rant again, but was it really necessary to split the
> configure.ac changes into 9 commits? What good will come of going atomic
> with such single liners as "Quote AC_COMPILE_IFELSE() input" or "Trivial
> whitespace changes and reordering", *REALLY*?

There are lots of big advantages to having small, independent patches
for independent problems / improvements.

I agree it doesn't make much sense to spend lots of time on pulling
apart bigger patches; but if you can make them as small commits
_in the first place_, it is _less work in total_ even.

And, in this case, I know for a fact that some of those were created
as these three-liners (I suggested one of-em, the quoting thing --
newer autoconf complains without it).

Segher

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev

Gmane