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
