Well, here's how I've been treating this. The ca0132 driver was made for the Chromebook's ca0132 chip. So in my mind, QUIRK_NONE is the Chromebook, and any added support for other cards is something that has been tacked on top of it's base. I don't know of any Core3D based cards that work just fine by going through the default setup without some sort of QUIRK related fixes. I don't envision ALSA getting floating point decibel volume, but I guess if that were to happen, maybe this could become an issue. In my mind, there is probably a reason Creative didn't make any reference to that verb on the driver that they, the people with the actual documentation, wrote. I try not to make any changes to things that I have no real reason to make a change to. It worked fine before without it, so I see no reason to begin doing that. But, if you believe that it's a necessary thing to do, then I guess you can. I just don't like touching things that I don't need to. On Sat, Jun 16, 2018 at 8:56 PM, Alastair Bridgewater <alastair.bridgewater@xxxxxxxxx> wrote: > That makes a certain amount of sense, but there are a few things that > would invalidate that reasoning. First, the contrived scenario: > Running Linux on the Chromebook with the sound card routed to a Qemu > VM running Some Other Operating System. Second, there's no quirk > matching for the Chromebook, which means that every unknown card (and > these unknown cards would presumably have the opportunity to be > dual-boot windows devices) would be denied the benefit of having the > extra volume bits cleared. Third, if Linux starts to use those extra > bits, and someone is dual-booting between kernel versions, we get the > same effect. > > At this point, unless there is reason to expect that clearing these > volume parameters could be harmful, I think that doing so globally is > the right thing. I can prep a patch for that in a day or so. > > On Sat, Jun 16, 2018 at 11:37 AM, Connor McAdams <conmanx360@xxxxxxxxx> > wrote: >> >> Going through the code again today, I realized why I did this. I don't >> believe the Chromebook will ever go into Windows, so I don't think I >> have to set the 0x797 and 0x798 audio volume verbs to 0x00 on it. I >> did this so that the Alienware laptops, which probably have booted >> into Windows, would have those values set to 0 if they hadn't been >> already. >> >> On Fri, Jun 15, 2018 at 9:56 PM, Alastair Bridgewater >> <alastair.bridgewater@xxxxxxxxx> wrote: >> > Commit e93ac30a32a6ba7ac3b4b2a4379af1dadb91e505 (ALSA: HDA/ca0132: >> > add extra init functions for r3di + sbz) introduced an extra >> > initialization function that was improperly guarded, taking effect >> > on systems with QUIRK_ALIENWARE, even though such systems were >> > supposedly not affected. >> > >> > It may be that this piece of initialization should be done for all >> > systems, but that's not a call that I can make. >> > >> > Signed-off-by: Alastair Bridgewater <alastair.bridgewater@xxxxxxxxx> >> > >> > diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c >> > index bdd626bde267..ca7375e48138 100644 >> > --- a/sound/pci/hda/patch_ca0132.c >> > +++ b/sound/pci/hda/patch_ca0132.c >> > @@ -7223,7 +7223,7 @@ static int ca0132_init(struct hda_codec *codec) >> > >> > snd_hda_sequence_write(codec, spec->base_init_verbs); >> > >> > - if (spec->quirk != QUIRK_NONE) >> > + if (spec->use_alt_functions) >> > ca0132_alt_init(codec); >> > >> > ca0132_download_dsp(codec); >> > -- >> > 2.16.1 >> > >> > _______________________________________________ >> > Alsa-devel mailing list >> > Alsa-devel@xxxxxxxxxxxxxxxx >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
