I
was curious, as stated below, whether there was going to be any simple mechanism
in the new hotplug scheme to notify an app (which is communicating to a USB
device through libusb) when a device has been unplugged or when a new device is
plugged in (or a previously unplugged device is "re-plugged"
in).
Thanks.
When you are addressing the
hotplug capability it would be "nice" if:
1) A user could call a libusb method
and specify a callback method to be invoked if a USB device with a given VID or
given VID/PID is plugged in. From within that
callback, the serial number or "other" unique identification could be retrieved
(possibly via a call to libusb_get_device_descriptor without having to first
call libusb_get_device_list).
2) Given a unique device as found in
the return info from a call to libusb_get_device_list, the user could call a
libusb method for that device and specify a callback method to be invoked when
that unique device was unplugged. (This method would be available even if that
device were not yet opened -- since descriptor info is available before opening
the device.)
The reasons for this
are:
1) In our application, we will have
multiple units with the same VID/PID but unique serial numbers that we must keep
track of (whether they are plugged in or not).
2) We keep a list of units plugged
in when our app starts and that list will only grow during a "session" with that
app (in that, if a device is unplugged, it is simply marked as unplugged but is
not removed from our list; if a new unit is plugged in that is not on the list,
it is added to the list; if a unit is plugged in that was on the list, it is
simply marked as plugged in). Hence the need for serial number or "other" unique identification (especially when
the unit is unplugged).
Our concern for the moment with
libusb is Linux and the Mac. On Windows, using WinUSB, we can create a hidden
window and register it with Windows for hotplug notifications (both plug and
unplug events) and associate those events with our list
appropriately.
Thanks for your
efforts.
Philip Joslin
Microchip Technology
-----Original
Message-----
From:
Daniel Drake [mailto:dan <at> reactivated.net]
Sent: Sunday, November 22, 2009 10:47 AM
To:
libusb-devel <at> lists.sourceforge.net
Subject: [Libusb-devel] libusb-1.0.6 released
https://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.6/libusb-1.0.6.tar.bz2/download
Daniel Drake (3):
Refine timerfd header check
(#18)
Increase libusb_handle_events()
timeout to 60 seconds
v1.0.6 release
Ludovic Rousseau (2):
Darwin: fix warning in
darwin_error_str()
lsusb example: make print_devs()
static
Nathan Hjelm (1):
Darwin: allow devices to be opened
multiple times
I now plan to work on libusb-1.1 for
release before the end of the year.
Changes:
- hotplug through libudev
- use dedicated timing thread for
generating file-based timer events on
systems where libusb-level time tracking is
needed and timerfd is not
available (i.e. no change of behaviour for Darwin and
recent Linux
platforms, and recent Linux platforms will still
achieve "zero
threads")
- make libusb_handle_events() timeout
unlimited
No incompatible API or ABI changes,
but obviously a few functions will be added for hotplugging, the
libusb_handle_events() change is a slight change in documented behaviour, and
some functions will become redundant through the timing changes (e.g.
libusb_get_next_timeout() will always return 0)
Hotplug backends for other platforms
(Linux+HAL, linux-2.4, Darwin?) will hopefully follow soon after.
Daniel
------------------------------------------------------------------------------
Let Crystal Reports handle the
reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design,
integration and deployment - and focus on what you do best, core application
coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Libusb-devel mailing
list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
François.
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
RSS Feed