libusb-devel Mailing List for libusb

Hi,

I have a usbprint device and I'm trying to port a Windows test application
to talk to the printer. The printer was originally a winusb device but has
been updated to usbprint and the test application used a DLL based on
libusb-win32.

The DLL has been upgraded to libusb-1.0 but couldn't talk to the usbprint
device without changing the device driver. The recommendation was to use
usbdk so I have done this.

I can now enumerate the bus and select the required device but when I try
to open it with libusb_open() the device driver is changed from usbprint to
usbdk with a different PID/VID and the handle that is returned doesn't
connect to the device.

Is there a method to get the correct handle or to be able to communicate
with a usbprint device (not as a print driver)?

Regards


-- 

Chris Blood B.Sc(Hons) C.Eng MIET


*Risch Designs** Ltd*

*T: *+44 (0)161 660 3437
*M**: *+44 (0)7901 552935
*E:* c....@ri...
*W**: *www.risch.co.uk
<https://www.linkedin.com/in/chris-blood-0337822b/>

CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipient(s). It may
contain privileged and confidential information that is exempt from
disclosure under English Law and if you are not an intended recipient, you
must not copy, distribute or take any action in reliance on it.  Copyright
in documents created by or on behalf of Risch Designs Ltd remains
vested in Risch
Designs Ltd. If you are not the named recipient please notify the sender
immediately.  Whilst every possible precaution has been taken the contents
of this e-mail or attachment may contain software viruses that could damage
your own computer system. You should therefore carry out your own virus
checks before opening the attachment.
Risch Designs Ltd is a company registered in England and Wales with company
number 10509388. VAT number 265 7366 71

Registered office York House, 250 Middleton Road, Manchester, United
Kingdom, M8 4WA (No unsolicited mail please).

Hello
I want to be able to open a xBox360 controller using LIBUSB as backend since it has an andvantage to cross compile. In the application I used HIDAPI to successfully connect to an Joystick HID (LIBUSB_CLASS_HID), I can also read the input reports of the device. 
Is there a method of connecting open a xBox360 controller via HIDAPI, or is there a different API that I can use? Or do you have an example that to open it using LIBUSB?
All my attempts were unsuccessful, the USB is enumerated but fails to open return -12 on libusb_open and are unsure what it means?
Thank you

On 18/02/2020, 3.57, "Tim Roberts" <ti...@pr...> wrote:


>Getting comfortable with overlapped I/O is a critical skill for a  Windows USB programmer.
>The ResetEvent is absolutely not required.  Windows will automatically 
>reset the event when you call WriteFile again. Also, unless you're doing 
>several things at once, you can have GetOverlappedResult do the wait for 
> you.

Thanks.

I'm comfortable with overlapped io, no worries there.

What prompted this look into the internals of my library was
that I had accepted a contribution that did not all seem correct to me.

They had added thae ResetEvent and WaitForSingleObject apparently to solve some
issue and to me it looked like those are not needed and that GetOverlappedResult
is all it takes.

I take it that since we are doing both input and output (ie two things at once) it
is necessary to have the OVERLAPPED.hEvent to point to two different event objects,
but that is all?

wbr Kusti

On 18/02/2020, 1.49, "Pete Batard" <pe...@ak...> wrote:
> https://docs.microsoft.com/en-gb/windows-hardware/drivers/hid/sending-hid-reports-by-user-mode-applications?redirectedfrom=MSDN

Thanks, I had not found that.

I will heed that advice but this leaves one wonder what is the technical reason behind that.

What I'm trying to say is that from the device point of view what is the difference between
these two methods/calls?

How can a device respond to one method and not the other.

And why have a call that does not do (always) what it says on the tin?

Is that something to do with whether the report goes through an interrupt EP or the control EP?

I found this:

https://github.com/node-hid/node-hid/issues/245

And if I followed the discussion correctly then in that instance it was exactly opposite from what the MS doc says:
for the device in question WriteFile did not work but using HidD_SetOutputReport worked.

wbr Kusti

Kustaa Nyholm wrote:
> Using WriteFile is more complicated as it involves WaitForSingleObject/GetOverlappedResult/ResetEvent.

Getting comfortable with overlapped I/O is a critical skill for a 
Windows USB programmer.

The ResetEvent is absolutely not required.  Windows will automatically 
reset the event when you call WriteFile again. Also, unless you're doing 
several things at once, you can have GetOverlappedResult do the wait for 
you.

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

Hi Kusti,

On 2020.02.17 19:48, Kustaa Nyholm wrote:
> So my question is if there is any reason to use WriteFile/ WaitForSingleObject/GetOverlappedResult/ResetEvent,
> why not just always use SetOutputReport.

https://docs.microsoft.com/en-gb/windows-hardware/drivers/hid/sending-hid-reports-by-user-mode-applications?redirectedfrom=MSDN

I quote:

 > A user-mode application should use WriteFile

and

 > Some devices might not support HidD_SetOutputReport and will become 
unresponsive if this routine is used.

Regards,

/Pete

Hi,

not really (or at all) libusb issue but some knowledgeable people hang out here so I figured I'd fish here first.

I'm updating my HID library and I noticed that the library uses either

WriteFile or HidD_SetOutputReport to set an output report.

Using WriteFile is more complicated as it involves WaitForSingleObject/GetOverlappedResult/ResetEvent.

So my question is if there is any reason to use WriteFile/ WaitForSingleObject/GetOverlappedResult/ResetEvent,
why not just always use SetOutputReport.

Likewise for GetInputReport.

wbr Kustiu

As far as I know, libusb only uses the buffers you give it when you do a
transfer, so there is no buffer to flush.  This is different from serial
drivers, which generally have an RX buffer somewhere in the kernel so they
can be ready to receive serial data from the device at all times.

There might be a buffer on the device side, and you can usually flush it by
reading from it until your read times out (you'll have to choose what
timeout to use).

--David

On Sun, Feb 9, 2020, 1:50 AM Jaco <ja...@jd...> wrote:

> How do you flush all the data from an input buffer? There is a command to
> flush a serial input buffer. How do you do that using LibUSB?
>
> Regards.
>
>
>
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

How do you flush all the data from an input buffer? There is a command to flush a serial input buffer. How do you do that using LibUSB?

Regards.

Why should I use hidapi if it works with Libusb? Hidapi is one layer on top of LibUSB and as I stated hidapi that uses libUSB also does not work. The hidapi that uses hidraw works. But I got it working using LibUSB on the Pi 3 thanks.

-----Original Message-----
From: Nathan Hjelm <hj...@me...> 
Sent: 31 January 2020 06:39 AM
To: Jaco <ja...@jd...>
Cc: libusb-devel <lib...@li...>
Subject: Re: [libusb] Libusb does not work correctley on Raspberry Pi 3

If the device is HID then you should be using hidapi b not libusb.

-Nathan

> On Jan 30, 2020, at 4:07 AM, Jaco <ja...@jd...> wrote:
> 
> Is there anybody who can help me with this please???? 
> I would love to use linusb and not hidraw on both Pi3 and Pi4.
> 
> 
> -----Original Message-----
> From: Jaco <ja...@jd...> 
> Sent: 27 January 2020 03:03 PM
> To: 'libusb-devel' <lib...@li...>
> Subject: Libusb does not work correctley on Raspberry Pi 3
> 
> Hi all.
> 
> I have been pulling out my hair for the last 2 weeks. I have been developing software that communicates with an Inverter via USB. I use libusb with the free pascal binding. It works 100% on the Raspberry Pi 4 (Buster) . But as soon as I try to run it on the Pi 3 it will time out at random or the data will come through corrupted.
> 
> I have been testing now with libhidapi as well. The libusb version does the same as libusb itself but the hidraw version works fine.
> 
> So it seems that anything with Libusb on the Pi 3 does not work correctly. 
> 
> Where do I start and who can I ask to look at this problem?
> 
> 
> 
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

Hi all,

Currently, my conundrum is that a cross-compatible host application I have
been working on that is timing out for control transfers in emulation
testing, specifically in Windows where it is WCID compatible for WinUSB.

>From a use case perspective, I am writing target files from host to device
using DFU 1.1 protocol via control transfers.  The timeout is specifically
an issue in emulation testing due to the model's slowness, resulting in
timeouts for larger files.  On Ubuntu, setting the timeout value in
libusb_control_transfer allows me to bypass this timeout, but on Windows
10, it still times out.

Here's a sample libusb_control_transfer call that is timing out (returning
a -7 error code):

    retval = libusb_control_transfer(
                dev_handle_g,
                USB_REQUEST_TYPE_ICI,   // request_type
                DFU_GETSTATE,           // bRequest
                0,                      // wValue
                ifc_num_g,              // wIndex
                (unsigned char*)state,  // data
                sizeof(uint8_t),        // wLength
                0 //timeout
             );

I'm suspecting this is an issue with WinUSB specifically, since according
to this, control transfers are set to 5 seconds specifically.

Is there an easy way around this while maintaining cross-compatibility?
Avoiding having to make WinUSB-specific API calls would be ideal, but I'm
unsure if it's a necessary evil at this point.

Thanks in advance!

OK so it turns out I had to compile the source on the PI 3. I took some time to set-up a Pi3 and took the source and compiled it. Now it works the same on the Pi 3 as on the Pi 4. 

I am just sooo glad it is working now. 

 

From: Jaco <ja...@jd...> 
Sent: 30 January 2020 10:27 PM
To: 'Chris E' <sp...@gm...>
Cc: 'libusb-devel' <lib...@li...>
Subject: Re: [libusb] Libusb does not work correctley on Raspberry Pi 3

 

Here is a video of what I see. I made a little test program.

 

https://drive.google.com/file/d/1spiUfCP438Ew4I5oGlb_b1lSAGvnvQaY/view

 

Should I compile it on the Pi 3? I compile on the Pi 4.

 

 

From: Chris E <sp...@gm... <mailto:sp...@gm...> > 
Sent: 30 January 2020 02:15 PM
To: Jaco <ja...@jd... <mailto:ja...@jd...> >
Cc: libusb-devel <lib...@li... <mailto:lib...@li...> >
Subject: Re: [libusb] Libusb does not work correctley on Raspberry Pi 3

 

I've released a commercial product that relies on libusb on Pi 3 with no issue whatsoever.

 

I think more debugging is required.

 

On Thu., 30 Jan. 2020, 11:07 pm Jaco, <ja...@jd... <mailto:ja...@jd...> > wrote:

Is there anybody who can help me with this please???? 
I would love to use linusb and not hidraw on both Pi3 and Pi4.


-----Original Message-----
From: Jaco <ja...@jd... <mailto:ja...@jd...> > 
Sent: 27 January 2020 03:03 PM
To: 'libusb-devel' <lib...@li... <mailto:lib...@li...> >
Subject: Libusb does not work correctley on Raspberry Pi 3

Hi all.

I have been pulling out my hair for the last 2 weeks. I have been developing software that communicates with an Inverter via USB. I use libusb with the free pascal binding. It works 100% on the Raspberry Pi 4 (Buster) . But as soon as I try to run it on the Pi 3 it will time out at random or the data will come through corrupted.

I have been testing now with libhidapi as well. The libusb version does the same as libusb itself but the hidraw version works fine.

So it seems that anything with Libusb on the Pi 3 does not work correctly. 

Where do I start and who can I ask to look at this problem?



_______________________________________________
libusb-devel mailing list
lib...@li... <mailto:lib...@li...> 
https://lists.sourceforge.net/lists/listinfo/libusb-devel