During platform development we could validate that particular code path for Linux and after the platform launches Canonical could submit a DMI matching patch indicating they've validated it with this codepath and we should support _OSI of Linux (or whatever pre-agreed value we pick).
Well, that's basically the problem. _OSI("Linux") doesn't mean anything. Right now you'd like to interpret it as "Doesn't support I2S", but what do you want to happen once Linux implements I2S properly? Someone to remember to remove that DMI check? In this specific case that might end up happening, but in general we'd end up with an unscalable set of quirks and a bunch of hardware not running at its full potential. It's not an option.
You've pretty clearly explained the issues that you face with the current state of affairs. What stopped you from being able to do so earlier? What's the earliest you would have been able to explain them?
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Re: (c) happy medium
Date: 2015-03-16 04:41 pm (UTC)Well, that's basically the problem. _OSI("Linux") doesn't mean anything. Right now you'd like to interpret it as "Doesn't support I2S", but what do you want to happen once Linux implements I2S properly? Someone to remember to remove that DMI check? In this specific case that might end up happening, but in general we'd end up with an unscalable set of quirks and a bunch of hardware not running at its full potential. It's not an option.
You've pretty clearly explained the issues that you face with the current state of affairs. What stopped you from being able to do so earlier? What's the earliest you would have been able to explain them?