example/hotplugtest: Ignore unavailable devices #1425

sonatique · 2024-01-03T12:03:20Z

Depending on the devices or drivers, open() may return
LIBUSB_ERROR_ACCESS
LIBUSB_ERROR_NOT_FOUND
LIBUSB_ERROR_NOT_SUPPORTED
for devices "out of reach" to libusb.

mcuee · 2024-01-04T01:54:42Z

@tormodvolden

This should be good to be merged.

Even though Windows hotplug is not there yet, we can get the hotplugtest example ready first.

tormodvolden · 2024-01-04T09:19:43Z

Yes, this can be applied before the Windows hotplug is ready, but I am fine with waiting with such things until 1.0.27 is out.

mcuee · 2024-01-06T01:10:52Z

@tormodvolden

I tend to think it is better to merge before 1.0.27 release.

Test under Linux (Ubuntu 20.04), external USB Type-C Hub with PICKit 4 attached.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 004: ID 05e3:0612 Genesys Logic, Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 003: ID 1ea7:0064 SHARKOON Technologies GmbH 2.4G Mouse
Bus 003 Device 004: ID 04f2:b6dd Chicony Electronics Co., Ltd HD User Facing
Bus 003 Device 005: ID 1c7a:0575 LighTuning Technology Inc. EgisTec EH575
Bus 003 Device 006: ID 8087:0026 Intel Corp. 
Bus 003 Device 013: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 014: ID 03eb:2177 Atmel Corp. MPLAB PICkit 4 CMSIS-DAP
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ ./examples/testlibusb 
Dev (bus 4, device 1): 1D6B - 0003 speed: 10G
Dev (bus 3, device 5): 1C7A - 0575 speed: 480M
  Manufacturer:              EgisTec
  Product:                   EgisTec EH575
Dev (bus 3, device 4): 04F2 - B6DD speed: 480M
Dev (bus 3, device 3): 1EA7 - 0064 speed: 12M
Dev (bus 3, device 14): 03EB - 2177 speed: 480M
  Manufacturer:              Microchip Technology Incorporated
  Product:                   MPLAB PICkit 4 CMSIS-DAP
Dev (bus 3, device 13): 05E3 - 0610 speed: 480M
Dev (bus 3, device 6): 8087 - 0026 speed: 12M
Dev (bus 3, device 1): 1D6B - 0002 speed: 480M
Dev (bus 2, device 4): 05E3 - 0612 speed: 5G
Dev (bus 2, device 1): 1D6B - 0003 speed: 10G
Dev (bus 1, device 1): 1D6B - 0002 speed: 480M

Detaching the hub.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ ./examples/hotplugtest 
Device detached: 03eb:2177
Device detached: 05e3:0610

Attaching the hub: interestingly on the hub shows in the run log but not PICKit 4.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ ./examples/hotplugtest 
Device attached: 05e3:0612
Error opening device: Access denied (insufficient permissions)
Device attached: 05e3:0610
Error opening device: Access denied (insufficient permissions)

mcuee · 2024-01-06T01:11:13Z

@tormodvolden

I tend to think it is better to merge before 1.0.27 release.

Test under Linux (Ubuntu 20.04), external USB Type-C Hub with PICKit 4 attached.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ lsusb 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 007: ID 05e3:0612 Genesys Logic, Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 003: ID 1ea7:0064 SHARKOON Technologies GmbH 2.4G Mouse
Bus 003 Device 004: ID 04f2:b6dd Chicony Electronics Co., Ltd HD User Facing
Bus 003 Device 005: ID 1c7a:0575 LighTuning Technology Inc. EgisTec EH575
Bus 003 Device 006: ID 8087:0026 Intel Corp. 
Bus 003 Device 019: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 020: ID 03eb:2177 Atmel Corp. MPLAB PICkit 4 CMSIS-DAP
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 001: Dev 007, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 002: Dev 019, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 002: Dev 020, If 0, Class=Human Interface Device, Driver=usbhid, 480M
        |__ Port 002: Dev 020, If 1, Class=Communications, Driver=cdc_acm, 480M
        |__ Port 002: Dev 020, If 2, Class=CDC Data, Driver=cdc_acm, 480M
    |__ Port 003: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 005: Dev 004, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 005: Dev 004, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, Driver=[none], 480M
    |__ Port 010: Dev 006, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 010: Dev 006, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M

Detaching the hub.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ ./examples/hotplugtest 
Device detached: 03eb:2177
Device detached: 05e3:0610

Attaching the hub: interestingly on the hub shows in the run log but not PICKit 4.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ ./examples/hotplugtest 
Device attached: 05e3:0612
Error opening device: Access denied (insufficient permissions)
Device attached: 05e3:0610
Error opening device: Access denied (insufficient permissions)

mcuee · 2024-01-06T01:15:11Z

On the other hand, the above output is also kind of correct.

Once I use sudo, the error goes away.

Attaching the hub -- it does not show PICKit 4

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ sudo ./examples/hotplugtest 
[sudo] password for mcuee: 
Device attached: 05e3:0612
Device attached: 05e3:0610

Detaching the hub -- it shows PICKit 4.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ sudo ./examples/hotplugtest 
Device detached: 03eb:2177
Device detached: 05e3:0610

mcuee · 2024-01-06T01:27:22Z

Somehow I think the output of hotplugtest is not predictable under Linux for external hubs.

Adding a USB 3.0 USB Mass Storage to the USB Type-C hub.

The USB Type-C hub will show as two devices.

05e3:0612 -- USB 3.0 hub, the USB 3.0 card reader (05e3:0749) is attached to it.
05e3:0610 -- USB 2.0 hub, Microchip PICKit 4 (03eb:2177) is attached to it.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 007: ID 05e3:0612 Genesys Logic, Inc. Hub
Bus 002 Device 008: ID 05e3:0749 Genesys Logic, Inc. USB3.0 Card Reader
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 003: ID 1ea7:0064 SHARKOON Technologies GmbH 2.4G Mouse
Bus 003 Device 004: ID 04f2:b6dd Chicony Electronics Co., Ltd HD User Facing
Bus 003 Device 005: ID 1c7a:0575 LighTuning Technology Inc. EgisTec EH575
Bus 003 Device 006: ID 8087:0026 Intel Corp. 
Bus 003 Device 019: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 024: ID 03eb:2177 Atmel Corp. MPLAB PICkit 4 CMSIS-DAP
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 001: Dev 007, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 003: Dev 008, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 002: Dev 019, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 002: Dev 024, If 0, Class=Human Interface Device, Driver=usbhid, 480M
        |__ Port 002: Dev 024, If 1, Class=Communications, Driver=cdc_acm, 480M
        |__ Port 002: Dev 024, If 2, Class=CDC Data, Driver=cdc_acm, 480M
    |__ Port 003: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 005: Dev 004, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 005: Dev 004, If 1, Class=Video, Driver=uvcvideo, 480M
    |__ Port 007: Dev 005, If 0, Class=Vendor Specific Class, Driver=[none], 480M
    |__ Port 010: Dev 006, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 010: Dev 006, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M

Detaching the hub -- only shows PICKit 4 and the associated USB 2.0 hub device.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ sudo ./examples/hotplugtest 
Device detached: 03eb:2177
Device detached: 05e3:0610

Attaching the hub: only shows the associated USB 2.0 hub and USB 3.0 Hub.

mcuee@UbuntuSwift3 ~/build/libusb/libusb_git (master)$ sudo ./examples/hotplugtest 
Device attached: 05e3:0610
Device attached: 05e3:0612

mcuee · 2024-01-06T01:37:13Z

@tormodvolden and @RReverser

Take note the above comment is not toward this PR which is a good one, but rather it is toward PR #1350.

Match any device in hotplugtest by default #1350

sonatique · 2024-01-29T09:52:56Z

@tormodvolden : what about merging this one?

mcuee · 2024-01-29T13:36:17Z

@tormodvolden : what about merging this one?

@tormodvolden
I think this PR is good to be merged.

tormodvolden · 2024-01-29T22:54:32Z

I think it is fair (for a test utility or example) to report on the failed open. But I agree that "Error" is bit strong. It could just say "(Cannot open device) ...". You could argue that hotplugtest has no reason to open the devices and it should just list the detected attach/detach but I am sure there are reasons it is good to try opening the devices that are reported as attached. Maybe due to some error (in the code it is meant to test) it is not able to open the reported device even if it should be able to. Hiding this would be wrong for a test tool. If it is a test tool...

hotplugtest was intended as a simple example of using the hotplug API and not a full test tool to cover all kind of scenarios. Maybe we should fork off a more advanced tool for testing the library code. One step could be to track several opened handles and close the right ones on detach, for example. And not quit after two events...

sonatique · 2024-01-30T16:05:47Z

@tormodvolden Still not clear to whether you approve this small PR or not ;-)
If not: what could I do to improve it?

tormodvolden · 2024-01-30T22:06:29Z

If I understand your code correctly, you are just suppressing the error message. There are no other changes to the behaviour of the program. I prefer not to hide these messages, as explained above. I wouldn't see that as an improvement, or something that needs to be changed. How can you tell if e.g. LIBUSB_ERROR_NOT_FOUND means that there is a bug in the driver (or missing driver) that has nothing to do with the hotplug code (the case you would like to "hide") or if the hotplug code wrongly announced a device that is not present? What if the user wants to test a particular device, but forgets to set permissions correctly or use sudo? Should the program hide the error and make the user believe it tested it OK?

I will change the wording as I suggested above, since "Error" sounds a bit alarming, but it is not very important or urgent.

There is maybe a misunderstanding on what "hotplugtest" example is meant for and how it works.

What I suggest is to fork off a real testing tool for hotplug with bells and whistles, covering all kind of scenarios and corner cases, and leave this example simple as it is. Sorry I think I am just repeating myself :)

sonatique · 2024-01-30T23:33:46Z

@tormodvolden : yes, I am hiding error that are known to occurs with open and that have nothing to do with testing / showcasing hotplug features, pretty much like you did in stress_mt recently here: 5f9abfb

I think it helps to reduce noise and focus on real hotplug related issues, making this simple tool more efficient, reducing false problem detection, hence reducing time not well spent.

I agree that having a real test tool for hotplug would be a big plus for libsub-1.0, but given the interactive nature of hotplug and the diversity of possible test setup, it's not something easy to design.

In the meantime I think this little PR would help, but I leave it up to you of course.

tormodvolden · 2024-01-31T08:15:03Z

I fully support improving things for helping development. The context of my response is that I was explicitly @ pinged to merge this now while we are in release freeze.

I intend to work on a hotplug testing utility after the release, to be used for development (if no one beats me to it).

Commit 5f9abf was merged because stress_mt is used in the automated CI tests, and failed systematically. This was more important for the release verification process.

References #1425 Signed-off-by: Tormod Volden <debian.tormod@gmail.com>

tormodvolden · 2024-01-31T11:47:27Z

I will change the wording as I suggested above, since "Error" sounds a bit alarming

I did this already though :)

Depending on the devices or drivers, open() may return LIBUSB_ERROR_ACCESS LIBUSB_ERROR_NOT_FOUND LIBUSB_ERROR_NOT_SUPPORTED for devices "out of reach" to libusb.

sonatique mentioned this pull request Jan 3, 2024

Match any device in hotplugtest by default #1350

Closed

mcuee added the Examples Examples label Jan 4, 2024

mcuee mentioned this pull request Jan 22, 2024

hotplugtest example enhancement: to be able to list all the devices attached/detched #1441

Open

sonatique force-pushed the hotplugtests-fix branch from 2960643 to d45154a Compare January 29, 2024 09:54

tormodvolden added a commit that referenced this pull request Jan 31, 2024

examples/hotplugtest: Tone down message about failed open

853a5ea

References #1425 Signed-off-by: Tormod Volden <debian.tormod@gmail.com>

sonatique force-pushed the hotplugtests-fix branch from d45154a to 1081545 Compare February 4, 2024 22:30

mcuee mentioned this pull request Feb 5, 2024

Proper hotplug test utility #1455

Open

example/hotplugtest: Ignore unavailable devices

5a05636

Depending on the devices or drivers, open() may return LIBUSB_ERROR_ACCESS LIBUSB_ERROR_NOT_FOUND LIBUSB_ERROR_NOT_SUPPORTED for devices "out of reach" to libusb.

sonatique force-pushed the hotplugtests-fix branch from 1081545 to 5a05636 Compare February 13, 2024 10:04

sonatique mentioned this pull request Feb 27, 2024

windows: hotplug implementation #1406

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

example/hotplugtest: Ignore unavailable devices #1425

example/hotplugtest: Ignore unavailable devices #1425

sonatique commented Jan 3, 2024

mcuee commented Jan 4, 2024

tormodvolden commented Jan 4, 2024

mcuee commented Jan 6, 2024

mcuee commented Jan 6, 2024 •

edited

mcuee commented Jan 6, 2024 •

edited

mcuee commented Jan 6, 2024 •

edited

mcuee commented Jan 6, 2024

sonatique commented Jan 29, 2024

mcuee commented Jan 29, 2024

tormodvolden commented Jan 29, 2024

sonatique commented Jan 30, 2024

tormodvolden commented Jan 30, 2024

sonatique commented Jan 30, 2024

tormodvolden commented Jan 31, 2024

tormodvolden commented Jan 31, 2024

example/hotplugtest: Ignore unavailable devices #1425

Are you sure you want to change the base?

example/hotplugtest: Ignore unavailable devices #1425

Conversation

sonatique commented Jan 3, 2024

mcuee commented Jan 4, 2024

tormodvolden commented Jan 4, 2024

mcuee commented Jan 6, 2024

mcuee commented Jan 6, 2024 • edited

mcuee commented Jan 6, 2024 • edited

mcuee commented Jan 6, 2024 • edited

mcuee commented Jan 6, 2024

sonatique commented Jan 29, 2024

mcuee commented Jan 29, 2024

tormodvolden commented Jan 29, 2024

sonatique commented Jan 30, 2024

tormodvolden commented Jan 30, 2024

sonatique commented Jan 30, 2024

tormodvolden commented Jan 31, 2024

tormodvolden commented Jan 31, 2024

mcuee commented Jan 6, 2024 •

edited

mcuee commented Jan 6, 2024 •

edited

mcuee commented Jan 6, 2024 •

edited