libusb-devel Mailing List for libusb

Hi all,
I'm using libusb 1.0.22 + libusbk 3.0.7.0 to drive my device on Windows platforms (basically Win7 & 10). It works fine, but I have to authorize my application running as Administrator, otherwise libusb_open would return LIBUSB_ERROR_ACCESS = -3.
In Linux we can fiddle with udev settings to gain the USB access permission to normal users, but I don't know is there any way similarly in Windows, or is there any configuration of libusb/libusbk that can bypass the permission problem?
Any suggestion?
Best regards.
Eric

Le lun. 27 mai 2019 à 17:59, Kubicz, Filip
<Fil...@no...> a écrit :
> Hi All,

Hello,

> I’m writing to ask for your opinion on future of HIDAPI library.
>
> HIDAPI is a great cross-platform library for dealing with HID devices, both USB and Bluetooth. However, the repository is not maintained anymore.
> https://github.com/signal11/hidapi
>
> There is ongoing discussion, trying to reach original author to get the write access, but it was not successful so far:
> https://github.com/signal11/hidapi/issues/373
>
> There is a lot of forks of HIDAPI with fixes for various problems. On the other hand, most of them fix problems or extend the library for their specific use case. It would be great to have a common point where users could push their fixes and have them pulled in.
>
> Because libusb suggests using HIDAPI as a library for HID devices, it was suggested that libusb could host this repository:
> https://github.com/signal11/hidapi/issues/373#issuecomment-410151632
>
>
>
> Giving write access to a few contributors (some volunteered in the thread above) could be a good idea, and the efforts would go together instead of everyone creating new forks. Authority of libusb is probably enough to attract pull requests.
>
>
>
> Would it be possible for libusb to host HIDAPI repository on Github?

I think that is a good idea to host libhid in the libusb github organisation.
The libusb core admin team contains 6 members (including me) so at
least one of them would be available to add new members and avoid the
situation of a unresponsive maintainer.

If no one from the libusb object I will copy the libhid project, say next week.
Filip, ping me next week if I forget.

Unfortunately I don't know a way to transfer the pull requests and
issues from one github project to another.

Bye,

-- 
 Dr. Ludovic Rousseau

Hi All,

I'm writing to ask for your opinion on future of HIDAPI library.

HIDAPI is a great cross-platform library for dealing with HID devices, both USB and Bluetooth. However, the repository is not maintained anymore.
https://github.com/signal11/hidapi

There is ongoing discussion, trying to reach original author to get the write access, but it was not successful so far:
https://github.com/signal11/hidapi/issues/373

There is a lot of forks of HIDAPI with fixes for various problems. On the other hand, most of them fix problems or extend the library for their specific use case. It would be great to have a common point where users could push their fixes and have them pulled in.

Because libusb suggests using HIDAPI as a library for HID devices, it was suggested that libusb could host this repository:
https://github.com/signal11/hidapi/issues/373#issuecomment-410151632

Giving write access to a few contributors (some volunteered in the thread above) could be a good idea, and the efforts would go together instead of everyone creating new forks. Authority of libusb is probably enough to attract pull requests.

Would it be possible for libusb to host HIDAPI repository on Github?

filip Kubicz

On Fri, 17 May 2019 05:07:11 +0200, nicolas bats said:

>Hi,
>here's a crash log while running libusb-1.0.0.22 on macOS 10.12.6
>I've an USB device attached to the mac, if I unplug it while my app is
>running, I got this crash:

1.0.22?  Could you try with 1.0.23-rc1?  (the topic of this thread.)

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Hi,
here's a crash log while running libusb-1.0.0.22 on macOS 10.12.6
I've an USB device attached to the mac, if I unplug it while my app is
running, I got this crash:

Thread 12 Crashed:: org.libusb.device-hotplug

0   libusb-1.0.0.dylib            0x000000010e94c5e7
usbi_signal_transfer_completion + 23

1   libusb-1.0.0.dylib            0x000000010e953cd1
darwin_async_io_callback + 241

2   com.apple.framework.IOKit     0x00007fffb2dfe772
IODispatchCalloutFromCFMessage + 341

3   com.apple.CoreFoundation      0x00007fffb0ea9133 __CFMachPortPerform +
291

4   com.apple.CoreFoundation      0x00007fffb0ea8ff9
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41

5   com.apple.CoreFoundation      0x00007fffb0ea8f71 __CFRunLoopDoSource1 +
465

6   com.apple.CoreFoundation      0x00007fffb0ea0be5 __CFRunLoopRun + 2389

7   com.apple.CoreFoundation      0x00007fffb0ea0034 CFRunLoopRunSpecific +
420

8   com.apple.CoreFoundation      0x00007fffb0edfae1 CFRunLoopRun + 97

9   libusb-1.0.0.dylib            0x000000010e9510db
darwin_event_thread_main + 603

10  libsystem_pthread.dylib       0x00007fffc68bc93b _pthread_body + 180

11  libsystem_pthread.dylib       0x00007fffc68bc887 _pthread_start + 286

12  libsystem_pthread.dylib       0x00007fffc68bc08d thread_start + 13


hope this helps...

best regards,

Nicolas

Le mar. 30 avr. 2019 à 22:38, Sean McBride <se...@ro...> a
écrit :

> On Fri, 5 Apr 2019 12:22:14 -0600, Nathan Hjelm via libusb-devel said:
>
> >I'm pleased to announce the libusb-1.0.23-rc1 release.
> >
> >This release has been long awaited, with 52 commits since v1.0.22. I
> >plan to speed up the release
> >schedule from now on.
>
> We finally had time to test this here where I work (technically I used git
> master).  Everything seems fine for our usage of libusb.  We even tried
> under Address Sanitizer and Thread Sanitizer and found no issues.
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 se...@ro...
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
>
>
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

>If you were made of money, I'd suggest you hook up to a USB bus analyzer 
>and see if it offers you any hints.  They can often pinpoint timing edge 
>cases.

Actually I have access to a Beagle analyzer so that is probably the next
thing to do. I was hoping to avoid that and that there would be something
other than timing that hub adds to the equation but alas...

Thanks again!

wbr Kusti



This e-mail may contain confidential or privileged information and is intended solely for the person to whom it is addressed. If you have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from the alteration of this e-mail, or as a result of any virus being passed on or as of transmission of this e-mail in general.

Kustaa Nyholm wrote:
>> What USB chip are you using?
> It is PIC18F45K50

Ah, that's a fun device, but a slow one.   It might actually be timing 
issues.  Microchip has a large, active, and very helpful user base.   
You should ask your question on https://www.microchip.com/forums/ .  
Someone there has probably seen this before and can offer practical 
suggestions.

If you were made of money, I'd suggest you hook up to a USB bus analyzer 
and see if it offers you any hints.  They can often pinpoint timing edge 
cases.


> Also the current firmware is highly optimized for SDCC compiler
> so moving to XC8 compiler (which is required by m-stack and Microchip
> stack) is a risky business and potentially non trivial task.

Yes, it's a shame the various compiler packages aren't more compatible 
with each other.  You'd think an automated conversion tool could handle 
most of the weirdnesses.

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

Thanks Tim for replying.

On 14/05/2019, 7.50, "Tim Roberts" <ti...@pr...> wrote:

>What USB chip are you using?  
It is PIC18F45K50 

>Did you develop the USB engine yourself, or is it a known provider?  

The USB firmware is something from some opensource project whose
history has been lost so obviously it is a suspect. I've been through the
code a few times and fixed an issue or two, but I'm no expert in USB.

The logical thing I guess would be to move over to some more reputable
USB stack from Microchip or maybe m-stack from signal11.

I did once try to move over to m-stack which supports number of PIC 
devices but halfhearted efforts get it run on 45K50 did not produce
a working port.

Also the current firmware is highly optimized for SDCC compiler
so moving to XC8 compiler (which is required by m-stack and Microchip
stack) is a risky business and potentially non trivial task.

So before Doing the Right Thing (tm) I'm investigating if I can
get away with what I have.

>What you're describing can mean you have timing issues.  
> Adding a hub exacerbates the delays, and if your device is already on the edge of the spec, adding the hub can cause a failure.

That would (is) a bummer!

> Does it matter whether it is a powered or unpowered hub?

Good point, the device is self-powered but I've only tested it
with an unpowered hub. I will grab a powered hub to see if
it makes a difference.

Thanks again.

wbr Kusti


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


This e-mail may contain confidential or privileged information and is intended solely for the person to whom it is addressed. If you have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from the alteration of this e-mail, or as a result of any virus being passed on or as of transmission of this e-mail in general.

On May 13, 2019, at 12:47 AM, Kustaa Nyholm <Kus...@pl...> wrote:
> 
> I've got a home brewn device that work just fine when directly connected to my Mac. 
> But if I insert a hub inbetween it seems to reliability issues.
> Could this be a problem with my firmware?

What USB chip are you using?  Did you develop the USB engine yourself, or is it a known provider?  What you're describing can mean you have timing issues.  Adding a hub exacerbates the delays, and if your device is already on the edge of the spec, adding the hub can cause a failure.

Does it matter whether it is a powered or unpowered hub?
— 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Hi,

I'm not using libusb for this project but since there are knowlegeable people here I thought I'd have a go at asking here.

I've got a home brewn device that work just fine when directly connected to my Mac. 

But if I insert a hub inbetween it seems to reliability issues.

Could this be a problem with my firmware?

Any ideas how to debug this?

How does the situation in relation to my firmware differ when there is a hub or not in between the device and host?

AFAIU there is already one hub inside the Mac...

wbr Kusti



This e-mail may contain confidential or privileged information and is intended solely for the person to whom it is addressed. If you have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from the alteration of this e-mail, or as a result of any virus being passed on or as of transmission of this e-mail in general.

On May 6, 2019, at 7:45 PM, 손창범 <ckd...@gm...> wrote:
> 
> problem is this. When I send 1920(bytes) * 254 times, device reports LIBUSB_ERROR_NO_MEM.
> 
> I've changed it to 2000(bytes) * several times and Memory error appears at similar memory amount.

Are you sending this data in real-time, or are you trying to send it all at once?  You should only get about 10ms ahead of the device.  So, for example, you should two 1920-byte buffers, and when the first buffer is finished, send the third.
— 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Hello libusb team!


I'm dealing with usb headset(audio device).

last time I've asked question about control_transfer(copy protection) and I
've done with that issue.

But other issue comes up now.

My device supports PCM data format (sampling rate 48k). So I've loaded
suitable wav data and send it to device by ISOCHRONOUS transfer(descriptor
says that Audio-streaming data EP address 0x01)

And I've checked that proper sound comes out for a little time only.

problem is this. When I send 1920(bytes) * 254 times, device reports
LIBUSB_ERROR_NO_MEM.

I've changed it to 2000(bytes) * several times and Memory error appears at
similar memory amount.

I'm curious that is it just only my device doesn't support enough memory or
am I wrong with handle it. because I tracked packets by protocol analyzer

and found that well-operating drivers also send ISO transfers like me(just
load the pcm data and send it by ISO transfer).

thank you for your support!

2019년 4월 27일 (토) 오전 1:51, 손창범 <ckd...@gm...>님이 작성:

> Hello libusb team!
>
> I'm dealing with usb headset(audio device).
>
> I want to send libusb_control_transfer and failed with error code -9(error
> pipe : people say usually it means stall(invalid parameter))
> below is the contents
>
> bmRequest Type
>
> bRequest
>
> wValue
>
> wIndex
>
> wLength
>
> Data
>
> 10100001b
>
> GET_CUR
>
> GET_MIN
>
> GET_MAX
>
> GET_RES
>
> Control Selector
>
> (CS)
>
> Terminal ID
>
> and
>
> Interface
>
> Length of
>
> Parameter
>
> block
>
> Parameter
>
> block
> bmRequest Type : 10100001= 0xA1
> bRequest : 0x81 GET_CUR
> wValue : COPY_PROTECT_CONTROL 0x0100
> wIndex : 0x0100(0x01 :terminal ID  0x00 : Interface 0(alternate 0) )
> wLength : 0x0001(1byte)
> Data : I declared it like uint8_t data;
> And my code here
> r1 = libusb_control_transfer(dev_handle, 0xA1, 0x81, 0x0100, 0x0100,
> &data, 0x0001, 1);
>
> can it be the Issues like byte_ordering(my VS is little_endian order)
>
> Can you guys help me with correct this error?
>