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-in... https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/x86-codec-inf...
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