headers
Xiaofan Chen | 1 Mar 2010 01:03
Picon

Re: Unable to send a bulk out

On Mon, Mar 1, 2010 at 12:26 AM, dwegmull <david <at> wegmuller.org> wrote:

> One more piece of possible relevant information: my PC is running kernel
> 2.6.24-27-generic and my ARM board is running 2.6.32. Is anyone aware of a
> change in the kernel that might break the library? Sounds unlikely to me but
> stranger things have happened before...
>

I think you have sent this post before.
I would not think this is the problem.
But you can try to install a new kernel to your PC to test, right?

--

-- 
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Permalink | Reply | 0 comments |
headers
Kustaa Nyholm | 1 Mar 2010 08:11
Favicon

Re: xusb.c testing


> From: Pete Batard <pbatard <at> gmail.com>
> Date: Sun, 28 Feb 2010 00:35:30 +0200
> To: <libusb-devel <at> lists.sourceforge.net>
> Conversation: [Libusb-devel] xusb.c testing
> Subject: Re: [Libusb-devel] xusb.c testing
> 
> Could we have a general poll on whether we want xusb in the release then?
> 
> Personally, I'll take code samples over documentation any day, no matter
> how good the documentation, because it's a lot easier to see how
> everything is meant to come together through an actual example than it
> is through an lengthy academic description. Nothing beats practical
> implementation, really.
Oops, forgot to cc list:

Hear, hear, my sentiments exactly! Worked out, tried and true examples
over documentation any day, please!

br Kusti

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Permalink | Reply | 0 comments |
headers
Jere Knaappila | 1 Mar 2010 09:23
Picon

Re: libusb_handle_events_timeout does not poll new transactions

On Fri, Feb 26, 2010 at 3:28 PM, Pete Batard <pbatard <at> gmail.com> wrote:
> On 2010.02.26 10:57, Jere Knaappila wrote:
>> Second if line is never true?
>
> Was meant to be:
>   if ((DWORD)object_index == (nb_handles_to_wait_on-1))
>
> Should be fixed in r180 now.
>
I tested with the latest tree, and it fixed that issue.
And poll catches transfers that have been submitted when poll was active.

Br.
-Jere

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Permalink | Reply | 1 comment |
headers
Xiaofan Chen | 1 Mar 2010 13:22
Picon

Re: xusb.c testing

On Mon, Mar 1, 2010 at 6:46 AM, Pete Batard <pbatard <at> gmail.com> wrote:

> Not sure if you tried, but Gamepads and Joystick (and most HID devices)
> don't seem to generate reports unless they are physically being acted
> upon by the user. Have you tried moving the joystick around?

This time I press one of the buttons and it seems to work. Nice!

But there is a problem, after the test, the USB mouse no longer
works. I have two USB mouse, so I just use one USB mouse
and then plug the other one to type my email. The other one is
in the back of the casing.

> Now, I think the bad results on Linux are probably due to the bad
> computation of input report length (I'm coming to that shortly...)

mcuee <at> ubuntu64:~/Desktop/build/libusb1/libusb-pbatard/examples$ ./xusb
-i 046d:c054
046D:C054
Opening device...

Reading device descriptor:
            length: 18
      device class: 0
               S/N: 0
           VID:PID: 046D:C054
         bcdDevice: 5400
   iMan:iProd:iSer: 1:2:0
          nb confs: 1
(Continue reading)

Permalink | Reply | 9 comments |
headers
Xiaofan Chen | 1 Mar 2010 13:15
Picon

Re: xusb.c testing

On Mon, Mar 1, 2010 at 7:05 AM, Pete Batard <pbatard <at> gmail.com> wrote:

>>> Since Pete has a PICkit 2 as well. This is the test result for PICkit 2.
>
> I actually never got around to testing my PICKit2 with Linux, so thanks
> for reminding me ;)
>
> I have now pushed r181 that should (somewhat) improve xusb on Linux, as
> the computed input report length should be more accurate.
> Unless the input report length is the right one, I don't think we can
> expect accurate readout of input reports, so that would explain most of
> the issues reported (at least with interrupt).

Indeed. Here is the new test results for PICKit 2 under Ubuntu 9.10 64bit.

*****
mcuee <at> ubuntu64:~/Desktop/build/libusb1/libusb-pbatard/examples$ ./xusb
-i 04d8:0033
04D8:0033
Opening device...

Reading device descriptor:
            length: 18
      device class: 0
               S/N: 3
           VID:PID: 04D8:0033
         bcdDevice: 0002
   iMan:iProd:iSer: 1:2:3
          nb confs: 2
(Continue reading)

Permalink | Reply | 2 comments |
headers
Xiaofan Chen | 1 Mar 2010 14:13
Picon

Re: xusb.c testing

On Mon, Mar 1, 2010 at 9:07 PM, Xiaofan Chen <xiaofanc <at> gmail.com> wrote:

Results for Microsoft Wheel Mouse Optical (with the two buttons
and the wheel pressed). xusb works quite well with this mouse.

Did you notice the strange characters in the string descriptor?

mcuee <at> ubuntu64:~/Desktop/build/libusb1/libusb-pbatard/examples$ cat
testmsmouse.txt
045E:0040
Opening device...

Reading device descriptor:
            length: 18
      device class: 0
               S/N: 0
           VID:PID: 045E:0040
         bcdDevice: 0121
   iMan:iProd:iSer: 1:2:0
          nb confs: 1

Reading configuration descriptors:
             nb interfaces: 1
interface[0].altsetting[0]: num endpoints = 1
   Class.SubClass.Protocol: 03.01.02
       endpoint[0].address: 81
           max packet size: 0004
          polling interval: 0A

Claiming interface 0...
(Continue reading)

Permalink | Reply | 5 comments |
headers
Xiaofan Chen | 1 Mar 2010 14:03
Picon

Re: xusb.c testing

On Mon, Mar 1, 2010 at 8:22 PM, Xiaofan Chen <xiaofanc <at> gmail.com> wrote:

> This time I press one of the buttons and it seems to work. Nice!
>
> But there is a problem, after the test, the USB mouse no longer
> works. I have two USB mouse, so I just use one USB mouse
> and then plug the other one to type my email. The other one is
> in the back of the casing.
>

Of course this will happen since I am testing the mouse itself.
Maybe under Linux, the program can detach the driver and
then re-attach the driver before exit.

> mcuee <at> ubuntu64:~/Desktop/build/libusb1/libusb-pbatard/examples$ ./xusb
> -i 046d:c054
> Reading string descriptors:
>   String (1/3): "Logitech"
>   String (2/3): "USB Optical Mouse"

--

-- 
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kustaa Nyholm | 1 Mar 2010 15:25
Favicon

Java wrapper anyone?

Hi,

a recent post on rxtx mailing list brought up the subject of a Java wrapper
for libusb and the question on where should this be hosted.

My first reaction was that the libusb1.0 project would be natural place for
different language wrappers for itself. Thoughts?

As to how this (wrapping) wrapping should be done, in my view, it should be
as thin and transparent as for example JOGL for OpenGL, ie one to one
mapping of the C-API to the language (in this case Java) of your choice.

I'm going to create one for myself as soon as libusb 1.0 supports properly
the three major platforms (Linux, Mac OS X and Windows).

I've done this for libusb 0.1 with JNA and it took me just about two hours.

Here is a taste of my libusb 0.1 wrapper for Java:

First we need a few classes to represent the C-structures:

public class USB_dev_handle extends PointerType
    {
    }

public class USB_device extends Structure {
    public static class ByReference
    extends USB_device
    implements Structure.ByReference {
    }
(Continue reading)

Permalink | Reply | 3 comments |
headers
Xiaofan Chen | 1 Mar 2010 14:07
Picon

Re: xusb.c testing

On Mon, Mar 1, 2010 at 8:22 PM, Xiaofan Chen <xiaofanc <at> gmail.com> wrote:
> On Mon, Mar 1, 2010 at 6:46 AM, Pete Batard <pbatard <at> gmail.com> wrote:
>
>> Not sure if you tried, but Gamepads and Joystick (and most HID devices)
>> don't seem to generate reports unless they are physically being acted
>> upon by the user. Have you tried moving the joystick around?

So now I am testing the Logitech Dual Action Gamepad.

For the first run, I did not press a button.
For the second button, I pressed one of the buttons.
xusb seems to work fine. Very nice!

mcuee <at> ubuntu64:~/Desktop/build/libusb1/libusb-pbatard/examples$ ./xusb
-i 046d:c216
046D:C216
libusb:debug [libusb_init]
libusb:debug [find_usbfs_path] found usbfs at /dev/bus/usb
libusb:debug [op_init] found usb devices in sysfs
libusb:debug [usbi_add_pollfd] add fd 3 events 1
libusb:debug [usbi_io_init] using timerfd for timeouts
libusb:debug [usbi_add_pollfd] add fd 5 events 1
libusb:debug [libusb_init] created default context
Opening device...
libusb:debug [libusb_get_device_list]
libusb:debug [sysfs_scan_device] scan usb1
libusb:debug [sysfs_scan_device] sysfs descriptors available
libusb:debug [sysfs_scan_device] bus=1 dev=1
libusb:debug [enumerate_device] busnum 1 devaddr 1 session_id 257
libusb:debug [enumerate_device] allocating new device for 1/1 (session 257)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Xiaofan Chen | 1 Mar 2010 14:38
Picon

Re: xusb.c testing

On Sun, Feb 28, 2010 at 10:59 PM, Xiaofan Chen <xiaofanc <at> gmail.com> wrote:
> On Sat, Feb 27, 2010 at 10:24 PM, Xiaofan Chen <xiaofanc <at> gmail.com> wrote:
>> This one is for a Acer Keyboard. It seems to work fine except the Input Report.
>>
>> More information about the Acer Keyboard Report Descriptor.
>> http://www.microchip.com/forums/fb.aspx?m=377479 (Linux lsusb)
>> http://www.microchip.com/forums/fb.aspx?m=367960 (Windows HHD Trial Version)
>>
>> mcuee <at> ubuntu64:~/Desktop/build/libusb1/libusb-pbatard/examples$ sudo
>> ./xusb -i 04f2:0760
>
> Same test under Windows. The last output is a bit strange.
> "Testing bulk read using endpoint 82...
>   Entity not found".

New test under Linux with latest git.

I need to manually detach the driver as the default codes do not
detach the drivers for both interfaces (only one).

mcuee <at> ubuntu64:/sys/bus/usb/drivers/usbhid$ ls
2-2:1.0  2-2:1.1  2-3:1.0  bind  module  new_id  uevent  unbind

mcuee <at> ubuntu64:/sys/bus/usb/drivers/usbhid$ echo -n 2-2:1.0 | sudo tee
-a unbind
mcuee <at> ubuntu64:/sys/bus/usb/drivers/usbhid$ echo -n 2-2:1.1 | sudo tee
-a unbind

mcuee <at> ubuntu64:/sys/bus/usb/drivers/usbhid$ ls
2-3:1.0  bind  module  new_id  uevent  unbind
(Continue reading)

Permalink | Reply | 1 comment |

Gmane