Working fully in the open during development isn't currently an option for system vendors. What we currently attempt to do is ask our IHV's to submit patches early when possible and after systems launch if they need to match on DMI information or particulars about the system that were previously private.
We work with vendors like Canonical and Redhat for our platform enablement and certification purposes. Canonical has been working on a firmware test suite for a while that we actively use for finding and fixing issues with the firmware with relation to Linux. What about if you supported DMI patches submitted from them specifically after they have validated the code path from _OSI of Linux on platforms that it matters? I don't think every platform would need this.
You're CC'ed on a thread on LKML about this from this morning, but the XPS 13 in particular this could have been very useful. The touchpad runs way better in I2C mode but I2S audio isn't yet mature. A fully supported _OSI of Windows 2013 would mean that it's forced to I2C mode touchpad and I2S mode audio. A fully supported _OSI of Windows 2009 would mean PS2 touchpad and HDA audio. At least until the I2S audio is mature it would be a better experience for users to have I2C touchpad and HDA audio. 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).
Have you reached out to Microsoft to see if they'll be willing to share major differences and subsystems that have been implemented between OS versions? This sort of thing is NDA backed, so unfortunately it can't come from system vendors like Dell. Given how open source friendly Microsoft has been lately, you might have some more luck these days.
As the person above indicated though, you should look into getting connected standby support in the kernel. This doesn't affect the XPS 13, but there are platforms that will be needing to support connected standby when Windows 2013 _OSI is detected that will be on their way.
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}
(c) happy medium
Date: 2015-03-16 03:21 pm (UTC)We work with vendors like Canonical and Redhat for our platform enablement and certification purposes. Canonical has been working on a firmware test suite for a while that we actively use for finding and fixing issues with the firmware with relation to Linux. What about if you supported DMI patches submitted from them specifically after they have validated the code path from _OSI of Linux on platforms that it matters? I don't think every platform would need this.
You're CC'ed on a thread on LKML about this from this morning, but the XPS 13 in particular this could have been very useful. The touchpad runs way better in I2C mode but I2S audio isn't yet mature. A fully supported _OSI of Windows 2013 would mean that it's forced to I2C mode touchpad and I2S mode audio. A fully supported _OSI of Windows 2009 would mean PS2 touchpad and HDA audio. At least until the I2S audio is mature it would be a better experience for users to have I2C touchpad and HDA audio. 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).
Have you reached out to Microsoft to see if they'll be willing to share major differences and subsystems that have been implemented between OS versions? This sort of thing is NDA backed, so unfortunately it can't come from system vendors like Dell. Given how open source friendly Microsoft has been lately, you might have some more luck these days.
As the person above indicated though, you should look into getting connected standby support in the kernel. This doesn't affect the XPS 13, but there are platforms that will be needing to support connected standby when Windows 2013 _OSI is detected that will be on their way.