Hi, On 11/13/20 5:49 PM, Mark Brown wrote: > On Fri, Nov 13, 2020 at 01:06:48PM +0000, Rojewski, Cezary wrote: > >> For a very long time upstream was filled with "flavors" of drivers for >> Intel solutions. Having three available for BYT is a very good example >> of that. The division of what goes where wasn't exactly explicit either. >> This all leads to confusion - while community and users may feel >> confused about what's recommended and what they should actually be >> using, surprisingly (unsurprisingly?) developers were too. > > ... > >> Patchset presented here goes directly against that goal. We, Intel >> developers, are tasked with providing reliable, working solutions >> exposing best possible experience for our customers when dealing with >> our products. And thus solutions provided are called recommended. We >> don't deal with flavors and try-it-out-on-your-own-risk. > > My feeling here was that this is helping with this goal in that it's not > changing the defaults but is rather pushing the decision making process > from build time to runtime. This means that distributions are able to > ship the preferred implementations for all the platforms without causing > any issues for the hopefully small set of users who need or want to work > on a different firmware, if they've been doing something like sticking > with an alternative firmware for old users since things were working > they'll be able to smoothly transition over to the current recommended > default, eg leaving old users on the old firmware by default. That's a > bit of a niche use case but then hopefully all use cases for selecting a > non-default firmware are niche. > > It also means that people don't have to think about this so much at > build time, they can just turn everything on and not worry they'll cause > problems for people using the binary and still get the recommended > runtime behaviour by default unless the user actively does something Exactly. As Pierre-Louis mentions the Intel team does not have most of the affected hardware. Since I've been working on making BYT and CHT based devices work better with Linux as a side project for the last couple of years I have been buying these kinda devices 2nd hand when ever I can get one cheap and I've built a big collection of these (one might say this has gotten out of hand a bit) see here: https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/x86-tablet-info https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/x86-codec-info For my device collection (mostly the first link). As Pierre-Louis mentioned I've already been working with him on getting ready to move everything BYT/CHT related over to SOF. I've already been testing SOF on various devices with mostly ok results so far. But this is a process not a switch which we can simply throw. So I'm all in favor of this patch-set. With some luck we can switch the BYT/CHT default to SOF in Fedora for F34 beta (*), but doing that really sorta hinges on this patch-set so that users can easily try the old driver, both as a workaround for issues and to check if the problem is caused by the switch to SOF. Talking about doing this for Fedora 34, I think that switching the default there is a good idea (and I can make this happen) what do others think about doing this? Regards, Hans
