On Wed, 24 Feb 2021 09:14:41 +0100, Jaroslav Kysela wrote:
Dne 24. 02. 21 v 8:12 Takashi Iwai napsal(a):
On Tue, 23 Feb 2021 21:56:16 +0100, Jaroslav Kysela wrote:
Dne 23. 02. 21 v 17:20 Takashi Iwai napsal(a):
Of course, this implementation would make the integration much easier, and that's a big benefit. So I have a mixed feeling and not decided yet whether we should go for it right now...
I think that we can reconsider the LED handling implementation later, when someone brings something better on the table.
What worried me is the plan to expose this capability to user-space. If it's only a kernel-internal, we can fix it in the kernel and nothing else broken, but if it's a part of API, that's not easy.
So, if any, I'd like to avoid exposing to the user-space at first. (But then it comes to the question how to deal with a case like AMD ACP...)
I tried to propose a complete solution and the ACP was one strong reason for this kernel / user space API. So without the user space support, it's just a half solution for known issues.
Frankly, I don't see any drawback or a problem even if we remove this API later.
Removing the user-space API is absolutely no-go. The only exception would be either the case really no one uses it or it's too buggy and unfixable.
This is a special case. Even if those LED bits are ignored by kernel in future, we expect to be replaced with another layer. Thus the functionality must be retained.
Well, we cannot know whether the replacement really happens or happened, and hence we never kill the old one. That's the problem.
The LED group bits are just informal for the user space and it's expected to create the user controls tied to this LED functionality only in alsa-lib/plugins at the moment. The kernel may return an error when the user space tries to set those new bits when the API is deprecated and I believe that the hardware design faults like AMD ACP (without the hardware mute) are rare.
The experience tells us that users are creative enough to (ab)use a new ABI in any unexpected ways, and we have no control for it. So it's not about how alsa-lib is implemented but rather how ABI could be abused :)
Ok, I don't have other ideas. I don't agree with your argumentation for this particular case, where the functionality is marginal. Ideally, the AMD driver may be recoded to use double-buffering and software mute switch, so we should handle everything in the kernel space.
My argument is that we're trying to add too much freedom just for this "marginal" problem. Honestly speaking, I would feel rather more comfortable if it were a kernel control element that just does trigger the LED like the original patch from AMD guys. Then you cannot do much wrong. OTOH, creating a virtual capture switch and let alsa-lib handling the software mute, while PA should ignores the soft-mute but dealing only with the assigned mute LED... Sounds too complex to me.
thanks,
Takashi