Hi, On 2/25/21 3:59 PM, Mark Brown wrote: > On Wed, Feb 24, 2021 at 09:09:36PM +0100, Hans de Goede wrote: > >> Given that the use of mute LEDs itself is actually rare and especially >> the use of mute LEDs in combination with ASoC coming up with some >> generic configuration mechanism to allow userspace to tie the > > This seems like an optimistic set of assumptions - it may reflect > current laptops but it sounds like the sort of thing people might > deploy on future devices, never mind all the non-laptops that could end > up wanting to use this mechanism. > >> Not to mention that this would just be punting the actual problem >> of figuring out which control to use to userspace, while the kernel >> is actually in a better place to make this decision since the kernel >> already uses DMI based quirks to deal with model specific configuration. > > Again, this only works in cases where there's only one option for the > control that could be used. Which is the case in all the current models which I'm trying to get the mute LED supported on. In its current form this is all purely handled inside the kernel, so we can easily change / extend the mechanism later without any problems. OTOH adding an interface where userspace can runtime set which control to use for this, would require adding some userspace API for this. To me it seems like a really bad idea to add userspace API for this now, when we don't actually have hardware which needs this. Introducing userspace API for this now introduces a significant risk that we get the API wrong, since we don't actuall have a use-case where we actually need the suggested flexibility. And then if such a use-case does eventually pop-up we might very well have gotten the userspace API for this wrong. I'm not saying that we will never need such flexibility, but we do not need it *now*, so as I said before lets cross that bridge when we reach it. Regards, Hans
