iirc, -vesa got kinda bad after the advent of the "GPU". Cards didn't natively support VBE and emulated a subset of it just for compatibility purposes.

It's gotten worse these days. I don't know if I'd call it a bad thing though - with the push for hardware accelerated rendering to help with battery life on portable devices, many of the desktop environments have lost support for "software" graphics. They instead depend on software OpenGL support via llvmpipe and chug hard even on modern devices (if you don't have a driver installed) and VMs.

While under X it was possible to install a dozen drivers and - mostly - be able to cycle through them (auto detection sucked and continues to suck at matching drivers to hardware via manufacturer/device ids), DRM/KMS drivers are unfortunately another story. You often cannot bring up a KMS driver for one hardware on another and expect to be able to gracefully unload if it’s not supported. There KMS drivers that can’t be installed in parallel (you have to choose which set of cards to support over the other a priori), and there is a ton of legacy hardware that will never get KMS drivers working, ever.

Thanks for reminding me of that - we definitely ran into that some. It wasn’t always with proprietary drivers, though. I think there were cases where legacy intel or amd cards would be incorrectly brought up by the old non-KMS drivers and then the KMS driver wouldn’t load, or maybe vice-versa as there were definitely specific cards within generations of chipsets that were documented as working under KMS/DRM failing and we would have to resort to the legacy drivers.

> But the answer there is not to simultaneously ship both the free and the proprietary stacks.

We didn’t really have a choice given that there wasn’t a one-size-fits-all driver (we didn’t try simpledrm - iirc it went through phases of breakage). But truth be told, while nvidia was the worst and most painful to deploy and upgrade, aside from the issue that we had to choose which version of the nvidia driver we wanted to ship (until we got the conflicting shared dependencies situation worked out by hot swapping the components before loading the driver), it was the most likely to work with all the cards it advertised support for. Only issue there was older cards not supported on current kernel versions or lacking drm drivers altogether.

What do you mean by "natively support VBE" or "emulated"?

VBE is just a set of functions in the VBIOS to do modesetting and get information about the modes.

Inability to change EFI resolution is OK except with high-res (4k) discrete GPUs running without scaling. But that’s ok because you can do fake DPI scaling in software - the actual tissue is performance at 4k sucks if not hardware accelerated.

Bigger problem today is that EFI fb support is still in its nascence both manufacturer- and software-side. Manufacturers ship crap that’s not up to spec while some EFI FB handlers are too strict in what they expect or haven’t added quirks for some of the very common hardware you might run across.

I've no idea what you're talking about as far as EFI fb support goes. The spec literally does not provide a mechanism for a running OS to get anything other than a pointer to a linear framebuffer and the metadata you need to use it. There's nothing more to support. What quirks are you talking about?

I know you’re posting from the perspective of a Linux dev, but some of this was on FreeBSD (and some of it was not).

The EFI stuff was all on BSD, which took a lot longer to make that transition than Linux did. I didn’t dig into those as much as I did with the BIOS/VESA stuff as my role in the product was being slowly phased out at the time we added native EFI support but had plenty of devices where customers would resort to using CSM to workaround EFI framebuffer graphics driver issues.