[alsa-devel] [PATCH] alsa-lib/tlv: fix handling of raw value ranges

Benoît Thébaudeau benoit.thebaudeau at advansee.com
Fri Mar 30 17:59:55 CEST 2012

Takashi Iwai wrote:
> Benoît Thébaudeau wrote:
> > 
> > Benoît Thébaudeau wrote:
> > > Clemens Ladisch wrote:
> > > > I'll see if I can cobble together some TLV checking code ...
> > > 
> > > Great.
> > 
> > In all the hardware examples that I've found, the worst case for
> > holes is
> > always, like for the BD37534:
> > mute
> > hole
> > valid dB range
> > hole
> > 
> > So it's perhaps not worth developing something very complicated in
> > the kernel
> > to handle all possible cases of TLV range holes.
> Well, it's not only about the TLV dB information.  The user-space has
> no idea where holes exist, and we have no way to expose this
> information, so far.  That is, you can access to some random raw
> values and now you'll get always errors.  This is obviously a bug of
> the driver.
> So, please don't take it as an example to _fix_ the alsa-lib code.
> Making it working for such a buggy driver isn't called as a fix.
> It's called as a workaround.  And, a workaround is usually ugly.
> However, beyond that, there is a good advantage in your change; it
> can make the code more robust.  We should concentrate on that point.

Yes. This is not what I meant here. Clemens seemed to be about to propose
a generic solution in the kernel to handle hardware volume range holes so as to
remove them when exposed to the user space. What I meant in my previous message
was that his solution would probably be sufficient if it only handled one hole
between the mute value and the other values, and another hole after the valid
values. That would ease the development of drivers for these cases, and thus
avoid buggy drivers in the first place.


More information about the Alsa-devel mailing list