We use libusb to handle the USB interface.
To cater for support on various Linux distributions we ship two versions of this module that use different c libraries.
It has been discovered that the version using the older C libs does not cater for hot plug devices, that is USB devices plugged in after the driver has loaded.
Knowing this issue exists with the version using the older libraries the installer loads the 'newer' libusb by default and if it fails to load due to glibc version issues then we link in the older libusb.
In our tests thus far this only happens on older distributions, such Fedora Core 18. There is a possibility that the underlying USB interface on such systems does not support hot plug in any case.
Our main concern regarding this issue is that if a USB controller on such a system drops out it might not reconnect but in theory this should not happen.
Driver settings to over come hotplug issue
Starting with UPDD 6.0.557 we have added a number of settings to cater for underlying hotplug issues where a device is not detected after a replug by restarting the driver based on UPDD device status change triggers.
In these cases a running libusb process does not receive notification of device changes so unless the driver is restarted the device is not detected. We believe is a bug or limitation of udev. The only thing we can do here is restart the driver. Now in a case where no touch device is seen the driver can be configured to restart itself periodically (by default every 10 seconds) until a device is discovered.
| Setting |
Description |
| usb.abort_on_disconnect |
If set (1), when a USB device is disconnected the driver process will terminate with an exit code of -16
This is useful in environments where device reconnects are not recognised by a running process.
A wrapper script can launch the driver and re start it in the event of exit code of -16
|
| usb.abort_on_nodevice |
For systems using systemV the UPDD install / run scripts implement this approach by default.
If set (1), when no supported USB device is connected the driver process will terminate with an exit code of -16
This is useful in environments where device connects are not recognised by a running process. We have seen this specifically on Puppy Linux
A wrapper script can launch the driver and re start it in the event of exit code of -16
For systems using systemV the UPDD install / run scripts implement this approach by default.
Note: the driver will repeatedly restart if this setting is set and no supported device is connected.
This is intended mainly to provide resilience to disconnects rather than a hot plug solution. |