[prev in list] [next in list] [prev in thread] [next in thread]
List: libusb-devel
Subject: Re: [libusb] =?utf-8?q?double_enumeration_on_hotplug=2C_but_only_for?=
From: Nathan Hjelm via libusb-devel <libusb-devel () lists ! sourceforge ! net>
Date: 2023-08-14 22:01:42
Message-ID: fab783b6-c627-47a6-9d17-234455dc1ff9 () me ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
You will likely have to do something like that. libusb is responding to th=
e changes in the IOUSBPlane maintained by the kernel. Not sure why the tre=
e changed an extra time but the logs show the notifications coming in from=
the kernel. Is the software doing something that would cause re-enumerati=
on? For example, making a call to libusb_reset_device?-NathanOn Aug 14, 20=
23, at 2:28 PM, Richard Hughes <hughsient@gmail.com> wrote:On Mon, 14 Aug =
2023 at 17:58, Tim Roberts <timr@probo.com> wrote:I grant that this is unu=
sual, but what's the problem?The problem is that some clients watch for th=
e device to re-enumerateso that they know the device has been reset. I'm u=
sing libusb fromfwupd, and we need to put the device into bootloader mode,=
writefirmware and then put the device back into runtime mode.The net effe=
ct is that you end up in bootloader mode, just like you expect.Yes and no.=
In the example I gave with the logs the VID/PID isdifferent in bootloader=
/runtime modes, but in some devices the VID/PIDis the same in different mo=
des, and the modes just differentiated bydifferent HID usage pages for exa=
mple. I guess I could try and openthe intermediate device and read the des=
criptors and come up with somekind of heuristic on when to ignore the extr=
a device re-enumeration,or put some kind of artificial debounce delay in t=
he device hotplugcode but it really feels like it's working around the iss=
ue.Richard._______________________________________________libusb-devel mai=
ling listlibusb-devel@lists.sourceforge.nethttps://lists.sourceforge.net/l=
ists/listinfo/libusb-devel
[Attachment #5 (multipart/related)]
[Attachment #7 (unknown)]
<html><body><div><div>You will likely have to do something like that. libusb is \
responding to the changes in the IOUSBPlane maintained by the kernel. Not sure why \
the tree changed an extra time but the logs show the notifications coming in from the \
kernel. Is the software doing something that would cause re-enumeration? For example, \
making a call to libusb_reset_device?<br></div><div><br></div><div>-Nathan</div><div><br></div><blockquote \
type="cite"><div>On Aug 14, 2023, at 2:28 PM, Richard Hughes \
<hughsient@gmail.com> \
wrote:<br></div><div><br></div><div><br></div><div><div><div>On Mon, 14 Aug 2023 at \
17:58, Tim Roberts <timr@probo.com> wrote:<br></div><blockquote type="cite">I \
grant that this is unusual, but what's the \
problem?<br></blockquote><div><br></div><div>The problem is that some clients watch \
for the device to re-enumerate<br></div><div>so that they know the device has been \
reset. I'm using libusb from<br></div><div>fwupd, and we need to put the device into \
bootloader mode, write<br></div><div>firmware and then put the device back into \
runtime mode.<br></div><div><br></div><blockquote type="cite">The net effect is that \
you end up in bootloader mode, just like you \
expect.<br></blockquote><div><br></div><div>Yes and no. In the example I gave with \
the logs the VID/PID is<br></div><div>different in bootloader/runtime modes, but in \
some devices the VID/PID<br></div><div>is the same in different modes, and the modes \
just differentiated by<br></div><div>different HID usage pages for example. I guess I \
could try and open<br></div><div>the intermediate device and read the descriptors and \
come up with some<br></div><div>kind of heuristic on when to ignore the extra device \
re-enumeration,<br></div><div>or put some kind of artificial debounce delay in the \
device hotplug<br></div><div>code but it really feels like it's working around the \
issue.<br></div><div><br></div><div>Richard.<br></div><div><br></div><div><br></div><div>_______________________________________________<br></div><div>libusb-devel \
mailing list<br></div><div><a \
href="mailto:libusb-devel@lists.sourceforge.net">libusb-devel@lists.sourceforge.net</a><br></div><div><a \
rel="noopener noreferrer" \
href="https://lists.sourceforge.net/lists/listinfo/libusb-devel">https://lists.sourcef \
orge.net/lists/listinfo/libusb-devel</a><br></div></div></div></blockquote></div><div><br></div></body></html>
_______________________________________________
libusb-devel mailing list
libusb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic