Hi,
I just checked in some changes to ptal-mlcd that should hopefully make it
work better when invoked from USB hotplug scripts. I would appreciate any
feedback on these changes, particularly from you "hotpluggers" out there.
:-)
Specifically, I added a "-hotplug" switch, which tells ptal-mlcd to
"activate" (establish communication with the peripheral) right away at
startup, and to attempt to re-activate after a deactivation (loss of
communication with the peripheral, which could be caused by an unplug or
power-down of the peripheral or by a protocol error). If an activation
or re-activation ever fails (presumably due to an unplug or power-down),
then ptal-mlcd exits.
WARNING: I crashed my computer several times while developing this feature.
I'm not 100% sure, but it appeared to happen when trying to re-open
/dev/usb/lpX too soon after the deactivation while the kernel was still
handling the unplug event. I added a 1-second delay before the re-open
when using the "-hotplug" switch, and that seemed to make the problem go
away. However, it would be a good idea to save your work and sync your
disks when playing around with this feature, just in case. Of course,
due diligence is always in order when testing pre-release software such
as this, as Joe Piolunek so eloquently pointed out recently. :-)
Another potential problem here is that if you unplug and replug too quickly
(more quickly than 1-2 seconds), you might end up with two instances of
ptal-mlcd trying to use the same Unix-domain socket and USB device node,
and chances are that they'll break each other. I added this to my TODO
list to revisit.
I also haven't yet fixed the bug related to the lack of standard
input/output/error file descriptors when run from a hotplug script, so
the "</dev/null" workaround is still necessary.
David
|
