Re:Fedora 36: A brave new (DRM/KMS only) world
by jancsika on Sunday April 24, 2022 @03:38PM
(#31147529)
> The -f- version seems to do more video processing in the firmware rather than in the kernel. I can't tell you exactly what they do differently, but I'd assume that the -f- variant uses some kind of Broadcom magic and the non-f-version runs mostly in-kernel and therefore has different side effects when it comes to video processing.
What does it mean to do video processing "in the kernel?" I assume that cannot mean software decoding-- if that were the case I wouldn't be able to play back smoothly.
Re:Fedora 36: A brave new (DRM/KMS only) world
by stefan_ on Sunday April 24, 2022 @03:52PM
(#31147683)
This is only about "kernel mode setting" - basically interfacing the hardware that drives your displays, sets up HDMI (if you use that) and so on. For the Raspberry Pi specifically, the "fkms" for fake KMS means that you use the proprietary RPi firmware to talk to the display and setup your screen, while the kernel just throws over a framebuffer. If you use the non-fake KMS, you have the kernel do all that lower level setup but you get more direct access to the hardware that allows you to use multiple planes and so on.
Why have both? The firmware, being derived from what was a set-top box, has a lot of proprietary magic to make things work with displays, also specifically with things like the official RPi display.
vc4-fkms-v3d is a module, vc4-kms-v3d is an entirely different module. These correspond to files somewhere on your device that describe the device and how to operate it.
The -f- version seems to do more video processing in the firmware rather than in the kernel. I can't tell you exactly what they do differently, but I'd assume that the -f- variant uses some kind of Broadcom magic and the non-f-version runs mostly in-kernel and therefore has different side effects when it comes to video processing.
Switching between these changes the way the kernel deals with graphics, so that's probably why you see the mouse being smoother in one version and hardware acceleration being unreliable in the other.
I can't tell you why Chromium is being weird. It could be a Wayland/X11 issue, it could be a driver support issue, it could be firmware issue, or maybe it's got something to do with sandboxing (Ubuntu and its Snap sandboxing have caused hardware access issues for me in the past). I have no idea what DRDC is even supposed to do, I'm guessing it's an optimisation in the Chrome rendering engine but who knows at this point.
To get the answers you seek, you'll have to dig into source code, I'm afraid. Perhaps if you reserve engineer the requirements for Chrome to enable the setting you'll find a hint at what you need to do to your rendering software to get it to support Chrome's code.