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.
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 :)
Takashi