Xorg, Wayland or Mesa support for SBC GPUs?
by business_kid from LinuxQuestions.org on (#6FN7S)
Does anyone know if any of the GPUs used by the variety of competing small Arm SBCs have drivers in Xorg or Wayland? Is such support coming?
I can only speak for the RazPi 4, for which the OSS community uses a framebuffer (or swrast) driver. The Pi 4 specs claim 2x4K hdmi screens for the VideoCore GPU, but without a driver, it struggles to drive 1x1080p, which is pathetic.
What's worse is that the RPi OS, which they obviously paid Debian for, has some proprietary code that gives them better performance.
I saw emails on the raspberrypi.org forum archives from shortly before the Pi 4's release which led me to conclude Broadcom (the chip supplier) were being very tight with the data needed by Debian. But they look to have supplied graphics headers in /opt/vc/include/*, and libraries in /opt/vc/lib/.
Debian obviously signed a NDA. I know this because RPi OS did provide a utility 'vcgencmd' off the beaten track in /opt/vc/. That 'vc' probably stands for VideoCore, their gpu name. The source must be available, because Slackware Arm & Slarm64 supply it. One of the commands allows you to check clock frequencies of the various gpu sections. A comparison shows that the Debian OS uses parts of the gpu that the community can't turn on!
I don't want to reward that kind of thing by buying another if some other GPU is better supported. Arm's Mali GPU does seem better looked after, but I would like to find video acceleration working in somebody's GPU before I consider another SBC purchase.
What's really interesting is the output of Code:cat /opt/vc/lib/pkgconfig/* |moreSkipping the boring bits of the pkgconfig entries, and just copying the (compiled & installed) library descriptions, I get
I can only speak for the RazPi 4, for which the OSS community uses a framebuffer (or swrast) driver. The Pi 4 specs claim 2x4K hdmi screens for the VideoCore GPU, but without a driver, it struggles to drive 1x1080p, which is pathetic.
What's worse is that the RPi OS, which they obviously paid Debian for, has some proprietary code that gives them better performance.
I saw emails on the raspberrypi.org forum archives from shortly before the Pi 4's release which led me to conclude Broadcom (the chip supplier) were being very tight with the data needed by Debian. But they look to have supplied graphics headers in /opt/vc/include/*, and libraries in /opt/vc/lib/.
Debian obviously signed a NDA. I know this because RPi OS did provide a utility 'vcgencmd' off the beaten track in /opt/vc/. That 'vc' probably stands for VideoCore, their gpu name. The source must be available, because Slackware Arm & Slarm64 supply it. One of the commands allows you to check clock frequencies of the various gpu sections. A comparison shows that the Debian OS uses parts of the gpu that the community can't turn on!
I don't want to reward that kind of thing by buying another if some other GPU is better supported. Arm's Mali GPU does seem better looked after, but I would like to find video acceleration working in somebody's GPU before I consider another SBC purchase.
What's really interesting is the output of Code:cat /opt/vc/lib/pkgconfig/* |moreSkipping the boring bits of the pkgconfig entries, and just copying the (compiled & installed) library descriptions, I get
- Description: Broadcom VideoCore host API library
- Description: Fake brcmEGL package for RPi
- Description: Fake brcmGLES2 package for RPi
- Description: Fake brcmOpenVG package for RPi
- Description: Multi-Media Abstraction Layer library for RPi
- Description: VideoCore Shared Memory library for RPi