Stefan Seyfried wrote: > On Mon, Feb 26, 2007 at 07:43:21PM -0500, Mark Stosberg wrote: >> Stefan Seyfried wrote: >>> Yes, it is trivial. I also had requests to do something similar in suse >>> (basically "service alsasound restart" does all this for me, since it >>> kills the applications and reloads the drivers). >> Interesting. On Ubuntu, the equivalent script doesn't kill the >> applications. Anyway, the proposed solution doesn't just kill >> applications, it restarts them all, too. > > And if all the time that was put into creating these elaborate workarounds > was spent fixing the real bug, then we'd all not have to write mails about > that problem. So go ahead and file a bug for the kernel. > >> Suse apparently has users who would benefit from this solution as well. >> Here are some SUSE users who have broken sound-after-suspend: >> >> http://www.suseforums.net/lofiversion/index.php/t25585.html > > Of course. Since this is a kernel problem, it is very likely that most > distributions will see it. > >> One user there has a ThinkPad T21, so it likely the same sound card I have. >> > But maybe just because nobody even bothered to file a bug against the kernel. > It might also very well be that it is just not documented well enough. I > figure that you would not google for "pm-utils custom hook" if you had a > problem with sound after suspend. I will try to get this better documented > (and google-indexed :-), but this is where you can also help.
I assume you mean that this would be helpful if someone had published a pm-utils hook script with this workaround, which no one was yet (although it is trivial to do given the code Mandriva has already published for this). >> and as time passes, it will be less likely. It hasn't worked for the >> past seven years. Why would developer who knew how to fix this /not/ >> have fixed it yet? How long would you suggest users wait, rebooting >> their computers to get sound to work after they suspend? Two or three >> more years? > > I'll accept this argument once you can show me for example Takashi Iwai > telling you "i won't fix this, because your hardware is too old". > He never said this to me. I'm sorry, I didn't know any one more appropriate to contact. I've contacted Takashi about this now. > I am willing to include workarounds for drivers that can not be fixed. There > are some of those (a PCMCIA ISDN card for example, whose driver are derived > from reverse-engineered ISA-ISDN card code. Nobody really will touch such a > driver if it is not absolutely unavoidable). However, you need to convince me > that the driver cannot be fixed. > > I was adding workarounds in the powersave code, three or four years ago. Back > then, it was the only way of getting suspend to work at all. Today we are on > a different stage of development and general consensus is that adding these > workarounds does slow down development. Thanks for clarifying your perspective. >>> Until this happens, adding a custom hook to /etc/pm/hooks is trivial. >> Trivial for who? Trival for my retired father who runs Linux on a T21 >> and is already skeptical about Linux? Frankly, you have to be fairly >> savvy just to understand what needs to be done. > > Then go ahead and document it in a prominent place so that people googling > for help will find it. I tried to document the pm-utils hooks for my users > in http://en.opensuse.org/Pm-utils, but maybe i failed. OK. I may go ahead and package my work as a pm custom hook, then. I assume the variables set in /etc/pm/config are available in the hooks? Mark _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
