[LAU] mute laptop speakers with Intel HDA

Takashi Iwai tiwai at suse.de
Tue Aug 7 09:08:17 EDT 2007

At Mon, 06 Aug 2007 23:10:00 -1000,
david wrote:
> Arnold Krille wrote:
> > Am Montag, 6. August 2007 schrieb Fons Adriaensen:
> >> I assume most drivers are using the same interfaces to the
> >> kernel, and the same services, and that these are relatively
> >> stable.
> >> But I could be completely wrong...
> > 
> > Well, the kernel devs seem to change some interfaces rather often in binary 
> > incompatible ways. And sometimes even on purpose (to drive away blob-drivers 
> > like nvidia)...
> > 
> > So it can be that one of these changes introduced a bug hard to find and 
> > affecting only very few drivers. And as the developers will probably all have 
> > the lastest kernels, they don't want to wast time by debugging a problem 
> > fixed two kernel versions ago just because the user has 2.6.4 installed and 
> > doesn't use a half decent distro...
> Note: a decent distro (I've used several) doesn't necessarily have the 
> "latest" kernel - cuz the latest may still be in the very unstable realm.

No more true.  Distros nowadays try to pick up the latest one as much
as possible.  Take a look at recent openSUSE, Ubuntu, etc.
Of course, it's adventurous to switch to early -rc kernel.  But the
released kernel is supposed to be stable.  This reduces the
maintenance a lot.

However, distros stick with the older kernel version for their
"business" products, mainly for keeping the 100% binary and source
compatibility, which many ISVs prefer.
IOW, it's just the matter of money :)

> I know I've switched to newer kernels in the past and had whole bunches 
> of devices quit working - for instance, had USB quit working completely. 
> On one, networking quit working entirely, too. So when some developer 
> tells me to "test again using the latest kernel," perhaps you understand 
> why I'm not exactly eager to go do that?

Yeah, I can understand it, of course.  I have a bunch of machines with
older kernels, too.  But, you understand that if no report back from
the tester, the bug will be left simply broken?  Testing is a part of
development cycle, and testing on the same environment is the
important factor, as I mentioned.


More information about the Linux-audio-user mailing list