We can't expect users to perform firmware updates just to get things working, and in most cases we can't expect system vendors to do the firmware updates in the first place - imagine this code being cut and paste into a low-end system with a 6-month support cycle, and then figure out the probability that anybody's ever going to fix it once Linux works properly.
That's a really unfair double standard. If there's a BIOS issue and we can fix it in firmware and actively do fix it why can't we tell people to go and use it? That can keep quirks out of the kernel! There was a problem with a bunch of the recent E series machines that we issued a BIOS fix for related to keyboard repeating specific to Linux. People had no problem applying that update.

Why? Windows makes very little use of them. Worse, they tend to end up breaking in surprising ways when the kernel changes behaviour. They're a huge maintenance overhead, and reducing the number present is a huge win for everybody.
There are plenty of quirks in Windows drivers, they're obfuscated though and not as obvious since we don't see the source.

And it gets argued about for 3 months because Canonical have historically been dreadful at actually explaining this kind of thing. This is why I think we need to come up with a good process for doing this. If we have a template that can be copied and pasted and filled out to be included in the git commit for example I think it would go a long way. All the major questions about it that normally come up can be put in the commit itself.

We don't need to know about specific hardware. Saying something like "Our expectations for operating systems that report Windows 2013 support include Microsoft Precision touchpad support, working I2S audio for existing codecs and connected standby" at some point last year would have told us nothing other than that Dell were actually paying attention to what would be involved in integrating new hardware features, which is hardly proprietary information. Knowing which features are likely to be required by real hardware vendors helps developers prioritize appropriately.
OK. When possible I'll try to notify you of the things I know about. Right now - the big ones are:
* Intel audio will support something different for Skylake than we have for Broadwell (I2S). Intel will need to comment more on this though as the information I have is under NDA.
* Windows 10 platforms will introduce Modern Standby.
* PCIe SSD's will become very important.


In this specific case, the audio issue is down to driver support rather than anything to do with our claimed operating system. Using _OSI("Linux") to indicate that a driver (rather than the core OS) is missing functionality is a pretty awful thing to do. It would be more meaningful to provide a mechanism for switching at runtime (a defined ACPI method that changes hardware configuration and triggers a PCI hotplug event, for example) and then have the Realtek driver call that when it detects that it's unable to drive the hardware in question.
You're absolutely right that this is something that for Linux the core OS doesn't really indicate the functionality, it's more of a driver type thing.
The problem is that the EC needs to set the mode when the HW is turned on, not at runtime. The values that are cached from a previous cold boot and those are what's used. We're in discussion of better ways to do this for upcoming platforms. I do like the idea of a driver being able to request switching the mode at least for the next boot. I'll raise it with the team.