On Fri, 14 Jun 2024 13:42:05 +0200, Jaroslav Kysela wrote:
On 14. 06. 24 13:33, Takashi Iwai wrote:
On Mon, 03 Jun 2024 13:38:18 +0200, Mark Brown wrote:
On Fri, May 31, 2024 at 08:06:14PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
On Fri, May 31, 2024 at 05:17:43PM +0200, Takashi Iwai wrote:
On Fri, 31 May 2024 07:50:33 +0200,
I would say these are all bugs, they show the driver not correcting the value and allowing users to read back out of range values that were written. Even if the driver is accepting out of range values I'd expect it to transform them somehow when storing, the program will accept a mismatched read when testing this case but it will complain if the read value is not valid according to the control's info.
Ideally, yeah. But it's a whack-a-mole game, and my gut feeling is that it'd be better to enable the input validation globally, something like below.
Yeah, I mean I tend to think the whole accepting invalid values thing is questionable to start off with so I do think that's a good idea. That said we probably should still be fixing the drivers as well.
OK, I'm going to submit a patch set for addressing those.
I think that this check should be optional (as discussed some years ago), because the driver code can implement the validation / bitmask handling in a more efficient way that we can do in the ALSA core code. Those double checks are not so nice. But they may be enabled by default as suggested to log problems for users building custom kernels, IMHO.
Yes, what I've worked on are the coverage in HD-audio and vmaster code as well as the enablement of validation for user control elements. It's not about unconditional enablement of input validation.
thanks,
Takashi