These two functions are available in libusb (http://libusb.info/) and they are currently used by libgusb (https://github.com/hughsie/libgusb/pull/10), a GObject wrapper for libusb. Can we get them implemented in FreeBSD to make applications or libraries porting easier?
Hi, Can you suggest a patch to implement them in FreeBSD 12-current? /usr/src/lib/libusb I'm uncertain if the functions you mention are useful to FreeBSD in general including ports, or if it is better to stub them in the code where these functions are used. The function to get the parent USB device must be re-constructed in userspace by using the information obtained from: /usr/include/libusb20.h:uint8_t libusb20_dev_get_parent_address(struct libusb20_device *pdev); Also this introduce a couple of races, like what to do if the parent USB device vanishes, refcounts and so on. --HPS
I have no FreeBSD 12 installation. The machine I used to test libgusb runs FreeBSD 11.1-RELEASE. I can setup FreeBSD 12 in virtual machine if I have to provide some code running on it. I think libusb_has_capability is easier to implement. Do you think it is correct for libusb_has_capability to always return 1 for the hotplug capability? I found there is another missing function today: libusb_interrupt_event_handler. gvfs uses it in its MTP backend, and this is the only libusb function it calls. gvfs has an option to disable libusb support, so it doesn't cause build problems.
Hi, libusb is the same for -12 and -11. Just make a patch for your current system and I'll fix the rest. > I think libusb_has_capability is easier to implement. Do you think it is correct for libusb_has_capability to always return 1 for the hotplug capability? Can you check what is expected by the hotplug capability? What functions must be implemented when this capability returns 1? > I found there is another missing function today: > libusb_interrupt_event_handler. gvfs uses it in its MTP backend, > and this is the only libusb function it calls. gvfs has an > option to disable libusb support, so it doesn't cause build problems. Is this a variant of the existing "libusb_event_handler_active()"? Can you investigate a bit? --HPS
See also: https://fosdem.org/2021/schedule/event/porting_fwupd_to_the_bsd/attachments/slides/4473/export/events/attachments/porting_fwupd_to_the_bsd/slides/4473/Porting_fwupd_to_the_BSD_distributions.pdf https://nlnet.nl/project/fwdup-BSD/
Hi, libusb_has_capability() is now implemented: /usr/include/libusb.h: /* libusb supports libusb_has_capability(). */ /usr/include/libusb.h:int libusb_has_capability(uint32_t capability); --HPS
libusb_get_parent was introduced in libusb in: commit cfb8610242394d532778a483570089c2bed52c84 Author: Pete Batard <pete@akeo.ie> Date: Thu May 10 20:01:10 2012 +0100 All: Add parent and port topology calls * Adds libusb_get_port_number, libusb_get_parent and libusb_get_port_path * Linux implementation provided by Alan Stern, OS X by Nathan Hjelm * Unsupported for *BSD platforms It is a trivial getter that returns a parent libusb_device member. From what I can tell the parent_dev is never set in any of libusb's BSD osdep code.
Bumped into this in devel/py-pyusb port - it requires this function to initialize the Python bindings.