On 9/13/07, Elimar Riesebieter riesebie@lxtec.de wrote:
On Thu, 13 Sep 2007 the mental interface of Michael Bourgeous told:
A better option might be a patch to us428control to add a daemonize switch (which, of course, could be as simple as fclose()-ing stdin, stdout, and stderr, and dealing with any I/O functions accordingly).
Hmm, from my patch tascam_fw and tascam_fpga are installed to /lib/udev. The udev rules are calling these scripts which are almost doing what your udev rule is doing manualy, isn't it? There is one user [0], who came along with an rule similar to the attached which still works. My intention is not do rewrite usx2yloaders, but optimize it for distribution.
I don't know whether upstream is active to help? A statement from Karsten Wiese would be helpfull at that point ;)
But if your rule works for sure, I can distribute it with your allowness. There are still ugly sh -c calls I don't understand yet.
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361558
Thanks for your competent input ;)
Elimar
The sh -c was necessary to keep udev from hanging when loading the US-224 and US-428 (because of us428control). I don't remember why I chose not to use the existing scripts, but one thing I don't like about those scripts is that they will load the firmware for /all/ Tascam USB devices, not just the one currently being probed by udev. This could either confuse udev or try to load the firmware multiple times for each device, possibly resulting in errors. Unfortunately, all of the utilities involved (fxload, usx2yloader, us428control) expect the old hotplug-style device path (/proc/bus/usb/111/222) instead of the sysfs/udev-style path (what a mess this udev switch still causes).
I just spent the last three hours trying to fix this problem, and I can only come to the conclusion that udev is horribly broken. For example, my firmware load rule gets called not only when the USB device comes on, but each time ALSA adds a new device from the usx2y (i.e. control, mixer, PCM, etc.), resulting in a lot of wasted time, and many erroneous calls to usx2yloader. Moreover, the rule gets called once for every device /removed/, even though it says ACTION="add". Finally, it seems that every now and then, udev tries the whole process over again, even though the firmware is loaded and us428control is running. Why do we have to keep breaking things that work?
At any rate, I've made a slightly improved version of my previous script, which you may distribute under any free license, if it is found to be better than the alternatives.
Mike Bourgeous