[alsa-devel] alsa-tools -> usx2yloader
Hi all, according to Debian #436502 I am asking herefore if there are plans to port asx2yloader from the old hotplug to udev? Debian lenny/sid relies on udev only, though. Thanks in advance Elimar -- It's a good thing we don't get all the government we pay for.
On Tue, 11 Sep 2007 the mental interface of Elimar Riesebieter told:
Hi all,
according to Debian #436502 I am asking herefore if there are plans to port asx2yloader from the old hotplug to udev? Debian lenny/sid relies on udev only, though.
Thanks in advance
Attached is a patch for the Makefiles and an udev rule which should work anyway. I don't have TASCAM US-122 usb hardware handy, so I would be very pleased if someone could test it. Thanks Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-)
On 9/12/07, Elimar Riesebieter <riesebie@lxtec.de> wrote:
Attached is a patch for the Makefiles and an udev rule which should work anyway. I don't have TASCAM US-122 usb hardware handy, so I would be very pleased if someone could test it.
Thanks
Elimar
I can't remember for sure, but the included rules file might have problems loading the us428control program. I think there might have been problems I encountered with using the tascam_fpga script directly from udev, since us428control doesn't self-daemonize. I'll attach the .rules file that I use, which might be useful as an example to fix the .rules file provided already if it's found that there are problems with udev and the existing tascam_fpga script. As I recall, since us428control was still holding on to its stdout, udev would hang and not load any devices after the US-428. 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). Mike Bourgeous
On Thu, 13 Sep 2007 the mental interface of Michael Bourgeous told:
On 9/12/07, Elimar Riesebieter <riesebie@lxtec.de> wrote:
Attached is a patch for the Makefiles and an udev rule which should work anyway. I don't have TASCAM US-122 usb hardware handy, so I would be very pleased if someone could test it.
Thanks
Elimar
I can't remember for sure, but the included rules file might have problems loading the us428control program. I think there might have been problems I encountered with using the tascam_fpga script directly from udev, since us428control doesn't self-daemonize. I'll attach the .rules file that I use, which might be useful as an example to fix the .rules file provided already if it's found that there are problems with udev and the existing tascam_fpga script. As I recall, since us428control was still holding on to its stdout, udev would hang and not load any devices after the US-428.
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 path to source is always uphill! -unknown-
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
On 9/14/07, Michael Bourgeous <sts.nitrogen@gmail.com> wrote:
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?
I'm not sure whether it will help you, but I had similar problems when I converted over to udev - I ended up using the following as the rule: ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idProduct}=="8006", SYSFS{idVendor}=="1604", RUN+="/lib/udev/tascam" If I didn't do this, then udev called /lib/udev/tascam too many times (more than once!). I can't help right now, but I will have a look at this over this weekend to see if it still works. HTH, Jaime
On 9/14/07, j t <mark473@gmail.com> wrote:
On 9/14/07, Michael Bourgeous <sts.nitrogen@gmail.com> wrote:
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?
I'm not sure whether it will help you, but I had similar problems when I converted over to udev - I ended up using the following as the rule:
ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idProduct}=="8006", SYSFS{idVendor}=="1604", RUN+="/lib/udev/tascam"
If I didn't do this, then udev called /lib/udev/tascam too many times (more than once!).
I can't help right now, but I will have a look at this over this weekend to see if it still works.
HTH, Jaime
Ooops, sorry - my bad... :-( I included the wrong line. Try this: ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idProduct}=="8007", SYSFS{idVendor}=="1604", RUN+="/usr/bin/usx2yloader" That's better :-)
On 9/14/07, j t <mark473@gmail.com> wrote:
Ooops, sorry - my bad... :-( I included the wrong line. Try this:
ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idProduct}=="8007", SYSFS{idVendor}=="1604", RUN+="/usr/bin/usx2yloader"
That's better :-)
Thanks. Based on your advice and a little plodding through udev rules and /lib/udev files, I've come up with a new and improved rule set that only tries to load the firmware once, and loads it just for the device being probed. Mike Bourgeous
At Thu, 13 Sep 2007 02:23:36 -0600, Michael Bourgeous wrote:
On 9/12/07, Elimar Riesebieter <riesebie@lxtec.de> wrote:
Attached is a patch for the Makefiles and an udev rule which should work anyway. I don't have TASCAM US-122 usb hardware handy, so I would be very pleased if someone could test it.
Thanks
Elimar
I can't remember for sure, but the included rules file might have problems loading the us428control program. I think there might have been problems I encountered with using the tascam_fpga script directly from udev, since us428control doesn't self-daemonize. I'll attach the .rules file that I use, which might be useful as an example to fix the .rules file provided already if it's found that there are problems with udev and the existing tascam_fpga script. As I recall, since us428control was still holding on to its stdout, udev would hang and not load any devices after the US-428.
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).
Yeah, I'll add the daemonize option soon. (The patch is already on my local tree but I forgot my laptop at home :) Takashi
At Mon, 17 Sep 2007 17:17:29 +0200, I wrote:
At Thu, 13 Sep 2007 02:23:36 -0600, Michael Bourgeous wrote:
On 9/12/07, Elimar Riesebieter <riesebie@lxtec.de> wrote:
Attached is a patch for the Makefiles and an udev rule which should work anyway. I don't have TASCAM US-122 usb hardware handy, so I would be very pleased if someone could test it.
Thanks
Elimar
I can't remember for sure, but the included rules file might have problems loading the us428control program. I think there might have been problems I encountered with using the tascam_fpga script directly from udev, since us428control doesn't self-daemonize. I'll attach the .rules file that I use, which might be useful as an example to fix the .rules file provided already if it's found that there are problems with udev and the existing tascam_fpga script. As I recall, since us428control was still holding on to its stdout, udev would hang and not load any devices after the US-428.
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).
Yeah, I'll add the daemonize option soon. (The patch is already on my local tree but I forgot my laptop at home :)
... or an easy solution would be to use startproc (or start_daemon) to wrap us428control. And you can call killproc for ACTION=="remove", too. Anyway, an untested patch is below. Takashi diff -r e82775d19938 us428control/us428control.cc --- a/us428control/us428control.cc Mon Jun 04 15:16:24 2007 +0200 +++ b/us428control/us428control.cc Tue Sep 18 17:42:19 2007 +0200 @@ -63,9 +63,16 @@ static void usage(void) { printf("Tascam US-428 Control\n"); printf("version %s\n", VERSION); - printf("usage: "PROGNAME" [-v verbosity_level 0..2] [-c card] [-D device] [-u usb-device] [-m mode]\n"); - printf("mode is one of (us224, us428, mixxx)\n"); -} + fputs("usage: "PROGNAME" [-options]\n" + " -v level specify verbosity level (0..2)\n" + " -c card specify card number\n" + " -D device specify device string\n" + " -u device specify USB device name\n" + " -m mode specify running mode: us224, us428, or mixxx\n" + " -d daemonize\n", + stdout); +} + /* * check the name id of the given hwdep handle */ @@ -86,7 +93,34 @@ static int check_hwinfo(snd_hwdep_t *hw, return 0; /* ok */ } -int US428Control(const char* DevName, int mode, int y) +static void daemonize(void) +{ + pid_t pid, sid; + + if (getppid() == 1) + return; /* already a daemon */ + + pid = fork(); + if (pid < 0) + exit(1); + if (pid > 0) + exit(0); + + umask(0); + sid = setsid(); + if (sid < 0) + exit(1); + + if (chdir("/") < 0) + exit(1); + + /* Redirect standard files to /dev/null */ + freopen("/dev/null", "r", stdin); + freopen("/dev/null", "w", stdout); + freopen("/dev/null", "w", stderr); +} + +static int US428Control(const char* DevName, int mode, int y, int to_daemon) { snd_hwdep_t *hw; int err; @@ -109,6 +143,9 @@ int US428Control(const char* DevName, in if (verbose > 0) fprintf(stderr, PROGNAME ": US-X2Y-compatible card found on hwdep %s\n", DevName); + + if (to_daemon) + daemonize(); Midi.CreatePorts(); @@ -167,14 +204,18 @@ int main (int argc, char *argv[]) int y = 8; int mode = 0; int card = -1; + int to_daemon = 0; char *device_name = NULL, *usb_device_name = getenv("DEVICE"); char name[64]; - while ((c = getopt(argc, argv, "c:D:u:v:m:")) != -1) { + while ((c = getopt(argc, argv, "cd:D:u:v:m:")) != -1) { switch (c) { case 'c': card = atoi(optarg); + break; + case 'd': + to_daemon = 1; break; case 'D': device_name = optarg; @@ -214,18 +255,18 @@ int main (int argc, char *argv[]) } } if (device_name) { - return US428Control(device_name, mode, y) != 0; + return US428Control(device_name, mode, y, to_daemon) != 0; } if (card >= 0) { sprintf(name, "hw:%d", card); - return US428Control(name, mode, y) != 0; + return US428Control(name, mode, y, to_daemon) != 0; } /* probe the all cards */ for (c = 0; c < SND_CARDS; c++) { // verbose--; sprintf(name, "hw:%d", c); - if (US428Control(name, mode, y) == 0) { + if (US428Control(name, mode, y, to_daemon) == 0) { card = c; break; }
participants (4)
-
Elimar Riesebieter -
j t -
Michael Bourgeous -
Takashi Iwai