I think the idea of $random_component_vendor maintaining an up-to-date Linux driver themselves may be unrealistic, and laptop vendors probably won't be doing that for all of their components either. At least on Linux that tends to involve being a competent kernel developer, too, at least if you want to be the maintainer of the driver in kernel upstream.
If the OEMs that are interested in Linux support collaborated with distros and/or kernel/driver developers before the new hardware hits the shelves, even if they didn't plan on writing and supporting the drivers themselves, that might work. Otherwise there's always catching up to do, as you said.
For years now, I've also had nothing that didn't work on my now fairly old X240. Everything's pretty dandy. At some point the clickpad didn't work after resuming from suspend, though, and that was a major issue that really shouldn't happen on a laptop series that's supposed to have great Linux support.
Other than that (and the fingerprint reader initially not working even though it was supposed to be supported, but that wasn't a big deal), there's really been nothing that didn't work.
I agree. I wonder what the Windows model is, and is there a way to emulate that in Linux?
If there is a bug, exploit, whatever, good luck. If there is a newer version of the component with a minor difference (e.g. different range of serial numbers, different device id, etc) usually the newer driver won't work, so no bugfixes for you. However, you can keep on upgrading your windows version, at least within the same Service Pack and major version, sometimes longer, because the age-old driver will continue to work.
The way to emulate it would be "have a binary compatibility layer for kernel modules". However, this gets you old, broken, weird and incompatible drivers that just happen to run with the new version if you are lucky. Also, because every vendor will reinvent the wheel while doing the minimum amount possible, drivers will be less capable, come with weird special tools, crapware and a generally bad compatibility to devices from other vendors.
Believe me, the grass isn't greener on the other side, just different.
If this laptop has Insyde BIOS, the relevant utility is called "H2OFFT-L" (Insyde H2O Firmware Flash Tool - Linux). In the worst case, you might have to run a tool from DOS.
FWIW, I've also used fwup and it has worked perfectly, so that's something that Lenovo did get right.
> I think Linux support of new hardware is always going to be shaky unless we can get vendors to care and support it themselves.
This is what I actually expect from a Ubuntu-certified laptop. That the manufacturer makes sure that the Laptop actually works with Ubuntu.
That's the same bar I have for Apple and windows laptops.
Otherwise they should just call them "Linux tinkerer friendly" or similar.
Waiting 7 months to be able to use sound was not an option for me. I needed to use the microphone and headphones for work.
Luckily I managed to get Arch set up, which came with a recent enough kernel and SOF driver. As of June 2020, Ubuntu still does not.
I also have had great experience with fwup. I've gotten tons of bios, firmware, microcode etc updates from Lenovo and they all apply seamlessly.
I think Linux support of new hardware is always going to be shaky unless we can get vendors to care and support it themselves. Otherwise, we have to wait and let the open source devs make drivers after the hardware is released.