With this specific case we were intending to issue another BIOS update later to remove the _REV check after I2S audio was mature in Linux. To us this means the patches to the kernel and userspace are upstream and included in the current stable release of all the major distros.
To me there are always going to be quirks. Even if we had talked about all this stuff sooner, we'd have a quirk in the kernel. It's not a trivial amount of effort to add support for some new technologies, especially when it's the responsibilities of our IHV's with other priorities.
Lets say there was a hypothetical scenario we had something like _OSI of Linux to get out the door in the modes we wanted. Canonical submits a patch to allow _OSI of Linux and in the patch documents exactly why _OSI of Linux needs to be enabled for this HW. When the things that they documented change and someone notices, that patch gets dropped. If no one notices, the hardware keeps working. At least it's a better result than us needing to issue a BIOS update to drop the firmware change for checking for _REV when things are stable in the kernel. Furthermore it matches the inflection of a particular kernel version that the software is actually supporting of the subsystem. For the XPS 13, I2S audio is sorta there for 4.0, so probably 4.1 it would have made sense to drop the quirk if the rest of it landed.
What stops us from doing this earlier? We don't tell people about our hardware until we're ready to sell it. It wasn't public knowledge that the new XPS 13 was coming after CES. Even if we did mention new HW was coming as a teaser, it wasn't public knowledge that it would have a Microsoft Precision touchpad or take advantage of a codec that could use multiple audio modes. Mentioning any of this (especially with a DMI information) could have tipped off the impending hardware.
We're fine being as open as possible after the launch. That's why I believe if you had a trusted party like RH or Canonical vetting these things that would support a separate _OSI during development that they could make sure it makes sense at the time and add the DMI patch at launch.
Re: (c) happy medium
To me there are always going to be quirks. Even if we had talked about all this stuff sooner, we'd have a quirk in the kernel. It's not a trivial amount of effort to add support for some new technologies, especially when it's the responsibilities of our IHV's with other priorities.
Lets say there was a hypothetical scenario we had something like _OSI of Linux to get out the door in the modes we wanted. Canonical submits a patch to allow _OSI of Linux and in the patch documents exactly why _OSI of Linux needs to be enabled for this HW. When the things that they documented change and someone notices, that patch gets dropped. If no one notices, the hardware keeps working. At least it's a better result than us needing to issue a BIOS update to drop the firmware change for checking for _REV when things are stable in the kernel. Furthermore it matches the inflection of a particular kernel version that the software is actually supporting of the subsystem. For the XPS 13, I2S audio is sorta there for 4.0, so probably 4.1 it would have made sense to drop the quirk if the rest of it landed.
What stops us from doing this earlier? We don't tell people about our hardware until we're ready to sell it. It wasn't public knowledge that the new XPS 13 was coming after CES. Even if we did mention new HW was coming as a teaser, it wasn't public knowledge that it would have a Microsoft Precision touchpad or take advantage of a codec that could use multiple audio modes. Mentioning any of this (especially with a DMI information) could have tipped off the impending hardware.
We're fine being as open as possible after the launch. That's why I believe if you had a trusted party like RH or Canonical vetting these things that would support a separate _OSI during development that they could make sure it makes sense at the time and add the DMI patch at launch.