fbdev would only work on BIOS systems if you were using vesafb or had a hardware-specific framebuffer driver loaded. Vesafb would tend to cause problems with suspend/resume and needed to be configured with bootloader arguments (the kernel had no support for transitioning to real mode and the protected mode entry point for VBE basically never worked, so either the bootloader or the 16-bit kernel entry code needed to be used to do the mode setting). The -vesa ddx either ran in vm86 mode or used x86 emulation code so could do more setting at runtime. I don't know of any cases where vesafb would work and -vesa wouldn't. I did a bunch of the hardware enablement work for Ubuntu back in 2004/2005, so real world deployment experience here is in the millions.

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?

Yeah, we specifically disabled suspend and resume and supplied the needed parameters at boot time when “safe graphics mode” was selected. There were definitely cases where neither vesafb nor vesa worked for us and we resorted to our own basic framebuffer driver with out-of-band management of modes via exposed IOCTLs to bypass X’s logic here altogether.

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.