News for hackers. Stuff that matters.
Re:Writing to the Framebuffer (2018) by ablu on Tuesday June 02, 2020 @02:10PM (#23394070)
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.
Re:Writing to the Framebuffer (2018) by Jasper_ on Tuesday June 02, 2020 @05:10PM (#23396354)
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
Re:Writing to the Framebuffer (2018) by rowanG077 on Wednesday June 03, 2020 @02:32PM (#23406966)
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.
Re:Writing to the Framebuffer (2018) by Jasper_ on Thursday June 04, 2020 @01:39AM (#23412936)
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...

Re:Writing to the Framebuffer (2018) by nitrogen on Tuesday June 02, 2020 @08:25PM (#23398228)
Does the Nvidia proprietary kernel module provide a DRI interface?
Re:Writing to the Framebuffer (2018) by Jasper_ on Tuesday June 02, 2020 @08:29PM (#23398252)
Re:Writing to the Framebuffer (2018) by joezydeco on Tuesday June 02, 2020 @04:15PM (#23395824)
Embedded developers still need fbdev. There are lots of display-enabled SoCs that don't have or need a GPU.
Re:Writing to the Framebuffer (2018) by zozbot234 on Tuesday June 02, 2020 @04:35PM (#23395992)
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.
Re:Writing to the Framebuffer (2018) by joezydeco on Tuesday June 02, 2020 @04:48PM (#23396127)
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.
Re:Writing to the Framebuffer (2018) by jschwartzi on Tuesday June 02, 2020 @07:21PM (#23397722)
Incidentally, i.MX6 is an example of using the Linux fbdev with hardware acceleration.