The sad answer is that they can't be bothered to meet the quality standards expected for upstream kernel code. Easier to just throw garbage in a tarball and ship privesc vulnerabilities to millions of users.

Driver supports costs money, vendors make money when they sell chips.

They treat drivers and software as a cost-center, so the software quality is typically horrible. Can't be merged, won't be merged.

Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.

> Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.

I don't remember it that way. I remember buying motherboards and receiving CDs full of drivers for the many Windows versions. I remember having to scour the internet for drivers and finding a different one for each Windows version. I remember failing to find drivers for new versions of Windows because the manufacturer couldn't care less. I remember incredibly shitty manufacturer applications that took over one minute to display a window on the screen. I even managed to reverse engineer one of those into a free software user space driver.

> I remember buying motherboards and receiving CDs full of drivers for the many Windows versions.

There haven't been "many" Windows versions in the entire existence of Windows. I bet you don't remember getting different drivers for every service pack or security update.

> Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.

That's just not true. A lot of hardware support was stranded by OS version updates, especially pre-Vista and Win7. It's reached a point where Linux deals a lot better w/ some older hardware than any currently-supported Windows version.

A small handful of times over many decades when the driver model changed, not after every update.

There were a lot of drivers who will not work with new windows versions. Due for examples of changes in things expectedv in the inf file or the registry. Installing drivers in windows was a lot of pain.

Ok, but again when you talk about "new windows versions" you're talking about an event that happens very infrequently, and most drivers do continue to work for decades without needing to be updated across multiple major versions. Windows 7 drivers from 11 years ago generally speaking still work in Windows 10 today. Hell, even Vista drivers (14 years ago!) often still work. Contrast that with the Linux kernel where you have to recompile external drivers, what, every few weeks?

A couple of times since 1995, not every year.

Some of that is just getting rid of compatibility code for misbehaving drivers.

Not just hardware but even older Windows applications run way better on WINE than on Windows 10. Microsoft doesn't care about reverse compatibility or long-term support for consumers.

you made my day, now i have to stop trolling and get a job. Do the same ;)

I feel this must explain why every Android device I've owned has felt janky in some way, while with an Apple phone it just seems to work.

I second others: it is horrible, low quality code.

I spent lots of time looking at released drivers for things like wifi dongles and cheap Linux sticks/tablets, and there are all sorts of horrors. The wifi cards do not fully implement scanning or ad-hoc mode. Existing ioctls are ignored or implemented wrong. Sleep is used for thread synchronization. Android device drivers hardcode specific app names and apply fixups for them, presumably to prevent crashes.

Intel has much better code, at least in wireless drivers, but to be fair their jobs is easier, because most of the logic runs in the embedded processor, and you only get the binary blob for its code.

> Why can't the vendors just contribute their drivers to the kernel?

What makes you think they want to? They want you to buy the next chip and the next and the next, not keep using the previous one with a new OS.

> What makes you think they want to?

Do they not care about having a high quality product?

They do have a high quality product. And then you have to buy their next high quality product instead of continuing to use the old one. Their products are hardware, not drivers, and they get more money by selling more hardware rather than letting old hardware get updated.

Can't use the hardware without the drivers. If the driver is low quality proprietary code that can't be fixed or updated, they don't have a high quality product.

And yet here we all are with umpty billion Qualcomm SoCs floating around and nobody complaining about how Qualcomm's chips don't work well (except, of course, in comparison to Apple's).

The hard reality that Linux kernel driver model stalwarts must face is that the only measure that matters to these companies is profit margin, and the economics just are not in favor of upstreaming their drivers. So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?

> So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?

Absolutely. Google has more than enough power and leverage to solve this problem. Why doesn't it require manufacturers to upstream their drivers instead of enabling their shitty industry practices? Literally just make it a requirement for Google Play services licensing or something. The phone manufacturers will be forced to require it from the chip manufacturers as well.

Google already does a lot of good work getting open source firmware into chromebooks. It should do even more. Use all that intellectual property for good for once.

> Google has more than enough power and leverage to solve this problem.

Yep. They are using their power and leverage to stabilize the kernel driver interface so that this just stops being a problem.

> Literally just make it a requirement for Google Play services licensing or something.

Google already has enough trouble keeping manufacturers on Google Play without giving them even more incentive to develop alternatives like microG.

https://wccftech.com/oppo-vivo-xiaomi-and-huawei-band-togeth...

https://wccftech.com/huawei-executive-says-the-company-wont-...

Android really needs the chip makers more than the chip makers need Android.

> Do they not care about having a high quality product?

No.

They care about maximizing shareholder value. If shipping lots of hardware with barely functional drivers integrators need to beat up into shape makes the most profit, that's what they'll do.

If you spend $20K more on making the software work, then it pays off paying $1 less for a part with a crappy driver than buying one from a vendor who also provides great software for anything you intend to sell more than 20K units.

Nowadays, a lot of products go out of production and are replaced by the next model before they have time to settle and get a consumer reputation. It sometimes feels like they do only 1 production run per model and then bye-bye. So, quick and "good enough", "as good" or "not worse than others" is good enough :-/

AMD already does and that creates a lot of friction both due to the bloat of the kernel the majority of which is now the AMD driver and the issue with code conventions and quality.

Unless hardware vendors agree to support a generic driver for each device type which can be maintained by the Linux kernel team it’s going to be a total nightmare and even then you need an easy model to extend the generic driver with a device specific one through an easy interface.

The AMD driver bloat is the register definitions. They have like 100+ MB of autogenerated register defines, some duplicated 8 times for each unit instance, for every chip generation and variant.

It's not real code, though it is ugly as heck and I have no idea why AMD can't do it a saber way.

They might want to keep their driver source closed, and even if they don't upstreaming code into the kernel is simply a ton of extra work.