undefined | Better HN

0 pointsComputerGuru3y ago0 comments

IIRC in real-world testing on actual consumer hardware in the field (sample size in the hundreds of thousands), we found fbdev was better supported than vesa (with more restrictions, of course).

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.

0 comments

2 comments · 1 top-level

mjg593y ago· 1 in thread

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?

ComputerGuruOP3y ago

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.