You still have the source to the old drivers. It's just not a priority for others to support anymore, but you have the means to go add that support yourself, or pay a third party to do it for you.

Contrast with when windows changed the video driver architecture in Vista, and the only option you had was to pound sand.

Seems like a pretty easy cost/benefit analysis to me:

I can either spend thousands of dollars worth of my time on updating the driver, or I can pay someone else thousands of dollars to do it. Or I can spend a fraction of that on a new video card.

Seems like the only solution for Vista users is the only solution I'd ever have gone with, anyway.

Sure the cost/benefit works out the same for you (which is why no one has done the work), but that's different from the full set of options available to you in both cases.

How expansive do we want to be about what the full set of options is, though?

I tend to fall on the side of the root poster - if having a stable driver API means Linux gets more commercial driver support, then that's the one that has the highest cost/benefit in my book.

In practical terms, being able to hack on open-source drivers isn't particularly useful to me, but having an easier user experience with Linux on the desktop (and, more generally, having Linux on the desktop be something more than an also-ran) would benefit me immensely.

I skipped Vista, however my XP drivers were fully supported on the upgrade to 7.

Some xp drivers work on 7, most don't. Also unlike user space, you cannot run 32 bit drivers on 64 bit windows, so unless you were running 32 bit win7 you needed 64 bit xp drivers, which were rare. Are you sure you explicitly installed xp drivers and didn't just happen to have hardware where windows shipped matching drivers or could download them from the windows driver database? (Or downloaded an installer bundle from the manufacturer's website that just contained drivers for all supported platforms..)

Womp womp. Most of those netbooks are unusably slow anyhow, and were when they were brand new too. Run an older kernel on there and call it a day.

Sorry but a DirectX 11 class dual core APU is good enough for general purpose gaming.

And runnig legacy kernels? No thanks.

Which GPU is it specifically?

AMD Fusion Brazos APU, Radeon HD 6250

Certainly looks supported by /dev/radeon, just not /dev/amdgpu.

I didn't said it wasn't supported, I said:

> My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04.

Which holds true, because /dev/radeon no longer offers hardware video decoding support it once did unless I force enable it, and even then it usually leads to random X crashes when watching videos.

And then there is this,

"For one, AMD users can’t use applications that require OpenGL 4.3 or later without the fglrx/Catalyst drivers."

https://www.omgubuntu.co.uk/2016/03/ubuntu-drops-amd-catalys...

OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux. You can use fglrx with newer kernels just fine, it's just that user space went out of it's way to break support.

I really fail to see how that has anything to do with Linux's unstable kernel driver API.

> OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux.

Ah, the Linux evangelist blame-game. It's a big advantage of a system being so haphazardly thrown together from separately developed components. Start by blaming the choice of distro, end up at "Linux is just a kernel".

I mean, I feel like that's valid in the context of this discussion. That being 'Linux's unstable driver API designed to push drivers as source into mainline causes ISVs headaches'.

How does that apply here when Linux didn't change and you can still use the same kernel driver, but some other component decided to not work with the driver anymore?

Given that the radeon driver doesn't provide the same feature set as fglrx used to provide, with the same stability, it is surely a driver issue.

... a brand new, mainline kernel will run fglrx just fine. It's user space (specifically the x srever) that decided to break fglrx. So how is that the fault of the kernel's unstable API again?

Graphics drivers run on the kernel.

I mean, everything runs on the kernel... but I assume you meant in the kernel.

Graphics drivers are split into three main pieces these days.

1) Kernel space that mainly sets up the GPU's MMU, and adds a context to the GPU's hardware thread scheduler. There'll be some modesetting too, but that piece is really simple (and fglrx never used the main kernel API for that anyway, so it doesn't really matter if it was stable or not. But it actually was pretty stable over the time frame we're talking about).

This piece still works fine on fglrx with a modern kernel.

2) A userspace component that lives with the window manager setting up the actual display output, and accelerating compositing. Stuff like EGL works by making IPC calls to this layer.

This is the piece that broke in your case, and only because the x server decided to change.

3) Another piece that runs in userspace and is ultimately what gets called by graphics APIs and is linked into every process making graphics calls. This is the vast majority of the driver.