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.
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
