On Mon, Jun 07, 2021 at 09:23:34AM +0200, Takashi Iwai wrote: > On Sun, 06 Jun 2021 16:16:44 +0200, > Geoffrey D. Bennett wrote: > > > > These two patches add support for reading the mixer volumes and mux > > configuration from the hardware when the driver is initialising. > > > > Previously the ALSA volume controls were initialised to zero and the > > mux configuration set to a fixed default instead of being initialised > > to match the hardware state. > > > > The ALSA controls for the Scarlett Gen 2 interfaces should now always > > be in sync with the hardware. Thanks to Vladimir Sadovnikov for > > figuring out how to do this. > > > > Takashi, if these pass your review, I believe that they are > > appropriate for: > > #Cc: stable@xxxxxxxxxxxxxxx > > Well, in general, having a proper fixed value for the initial mixer > value is the right thing, which is a part of the driver's role. > Though, in snd-usb-audio, we don't set up the initial values just > because of laziness; since the topology in USB audio is variable per > device and often hard to parse correctly, it's difficult to determine > the suitable initial values, hence we leave untouched. So, in that > sense, setting the zero isn't wrong, rather safer, per se. > > However, Scarlett 2 seems to want to be different; it has already some > initialization code to read the existing configs. So this change > sounds more or less acceptable. But it's questionable whether it's > really for stable as a "fix". For the Scarlett devices, the sensible (but not all good) initialisation options are: 1. Don't load configuration from hardware so the ALSA controls show default values not in sync with hardware. This is a bad user experience. 2. Reset hardware configuration to hard-coded defaults so ALSA controls will be in sync with hardware. This is a really bad user experience as it is common for the device to be configured using the proprietary vendor-supplied software and then connected to Linux with the expectation that the configuration is kept. 3. Load configuration from hardware so ALSA controls are in sync with hardware. This is a good user experience. Before these two patches, it was option (1) for the mix/mux controls and option (3) for the remainder of the controls. I would call this definitely not sensible behaviour. I got many queries as to the apparently strange workings of the driver due to this; certainly many users besides myself considered the original behaviour a bug so it does fit the rule "It must fix a real bug that bothers people" from Documentation/process/stable-kernel-rules.rst You might consider that it does not meet the "It must be obviously correct and tested" rule though, and I could agree with that. Perhaps leave it out from stable for now and revisit later after we get more test results? Is there a particular amount of time or number of test success reports that you would consider sufficient? > In anyway, please fix the bug ktest bot spotted, the missing endian > conversions and resubmit. Thanks, I have resubmitted. Regards, Geoffrey.
