[Pm-utils] code available to solve sound-after-suspend problems

[Mark Stosberg]

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