Re:Programming the Linux Framebuffer
by ComputerGuru on Wednesday January 31, 2018 @04:04PM
(#16277522)
We had trouble getting Xorg to reliably work for all customers on a live cd but after noting that the FreeBSD framebuffer always loaded and displayed info OK and could even support different resolutions we wrote a solution that would allow the frame buffer to serve as the x86/Xorg output device: https://github.com/neosmart/xf86-video-scfb
Now all X-enabled windowing toolkits can use the rock-solid framebuffer without modifications.
Linux's Xorg distribution already has a framebuffer driver for Xorg (or maybe even two different ones) that ships with it, but we didn’t have the same “works everywhere” experience we do with our custom solution (based off of netBSD’s previous work), perhaps due to framebuffer bugs on Linux or maybe something else entirely.
The drawback is that the higher the screen resolution (we weren’t happy with 800x600 due to LCD scaling blur from horrible on-controller scalers and instead decode edid data from the monitor/adapter to find the native resolution) the slower refreshes to the screen get. At high enough resolutions there is a clear order of 10-100ms delay in updates.
Now all X-enabled windowing toolkits can use the rock-solid framebuffer without modifications.
Linux's Xorg distribution already has a framebuffer driver for Xorg (or maybe even two different ones) that ships with it, but we didn’t have the same “works everywhere” experience we do with our custom solution (based off of netBSD’s previous work), perhaps due to framebuffer bugs on Linux or maybe something else entirely.
The drawback is that the higher the screen resolution (we weren’t happy with 800x600 due to LCD scaling blur from horrible on-controller scalers and instead decode edid data from the monitor/adapter to find the native resolution) the slower refreshes to the screen get. At high enough resolutions there is a clear order of 10-100ms delay in updates.