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

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

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.

>> > 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.
but none of that explains the design choice.
two questions require an answer, imo: a) why was is done this way and b) 
do you still consider it the right choice?

regards