Hacker News new | ask | show | jobs
by ablu 2206 days ago
My understanding was that fbdev is deprecated (but I was unable to find good info on this) and that one should use dumb buffers (https://manpages.debian.org/testing/libdrm-dev/drm-memory.7....) for this simple stuff / somewhat portable software rendering. At least Qt allows to do this for embedded devices without hardware rendering.
2 comments

Yes. fbdev is kept alive for compatibility (and fbcon) reasons, but it's a really outdated API and drivers have to jump through hoops to support it. Please use dumb buffers when necessary. See a simple example here: https://github.com/magcius/drmdemo
How can I write a simple device driver using dumb buffers? I have searched far and wide but I can't find anything. I'm forced to write a framebuffer driver. Once you dip into DRI shit get's insanely complex quick.
For the simplest case, where you have contiguous memory for your framebuffer storage and no MMIO, try the CMA helpers: https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

I wrote a basic device driver for a platform I worked on. It's since been upstreamed and gotten more eyeballs, but it's still relatively simple. https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

Does the Nvidia proprietary kernel module provide a DRI interface?
Embedded developers still need fbdev. There are lots of display-enabled SoCs that don't have or need a GPU.
But even then, not every display-enabled SoC is well modeled as a dumb framebuffer. The Raspberry Pi itself provides hardware overlays, and it's quite problematic to expose them under that kind of model. The DRM infrastructure seems to be a lot more general and flexible.
I wouldn't recommend an RPi for product development. There are better SoCs, like i.MX, with documented graphics pipelines and graphic/video/camera overlays that are easy to use.
Incidentally, i.MX6 is an example of using the Linux fbdev with hardware acceleration.