Re: [RFC PATCH] docs: sound: kernel-api: writing-an-alsa-driver.rst: add FIXMEs

[Takashi Iwai <tiwai@suse.de>]

On Thu, 20 Apr 2023 15:44:50 +0200,
Oswald Buddenhagen wrote:
> 
> On Thu, Apr 20, 2023 at 02:54:19PM +0200, Takashi Iwai wrote:
> > On Thu, 20 Apr 2023 14:47:11 +0200, Oswald Buddenhagen wrote:
> >> On Thu, Apr 06, 2023 at 08:42:27AM +0200, Takashi Iwai wrote:
> >> > On Wed, 05 Apr 2023 22:12:20 +0200, Oswald Buddenhagen wrote:
> >> >>  The ``name`` is the name identifier string. Since ALSA 0.9.x, the
> >> >>  control name is very important, because its role is classified from
> >> >>  its name.
> >> >> +// This is a questionable design, IMO. Why user-space heuristics when
> >> >> +// the driver could set the roles/capabilities? This would avoid
> >> >> +// problems like the Tone Control sliders (unlike the switch?!) being
> >> >> +// misclassified as applying also to capture.
> >> > > Why this has to be discussed here and now...?
> >> > why not?
> > 
> > Because it is the already defined rule, and you're complaining the
> > documentation.  You are free to start a new discussion, but not it
> > shouldn't be along with the documentation patch at all.
> > 
> this is a "various questions about the documentation" patch/thread. i
> can't think of a better place to discuss/document design choices.

But why this has to be buried in the middle of a patch containing lots
of other changes...?  Better to split out and start a new thread.

> 
> >> > It's the thing that was *defined* over two decades ago.
> >> > that may be so, but this doesn't explain anything.
> >> it's a somewhat surprising choice, and it does in fact sometimes cause
> >> problems. so at least it should be thoroughly explained.
> > 
> > Again, you're barking at a wrong place.  The whole control name ruling
> > is explained in another document; there is another document covering
> > control name rules.
> > 
> there is the control-names.rst document.
> if you agree, i'd actually move the entire "Control Names" section
> into it, to avoid redundancy.

I don't mind too much, but holding a brief description is always nice,
better than just mentioning another reference.  You can refer to the
other document for details, of course, though.

> but none of that explains the design choice.

The design choice was a looooong history, ca 25 years ago.

> two questions require an answer, imo: a) why was is done this way and
> b) do you still consider it the right choice?

IIRC, this was a result after struggles with the structured control
implementations.  It became too complex, and the plain array with
string representation can cover all complexity, while it still allows
the grouping in user-space side.

Again, the choice was done in a quarter century ago, and if you change
it, you'll certainly break the whole things badly.  We must keep the
compatibility.


Takashi