vc4-fkms-v3d and framebuffer

[ajefr]

Hello,

With the introduction of the new vc4-fkms-v3d with the RPI4, I encounter many problems with this new emulated framebuffer.

First trouble : It's impossible to increase framebuffer size. For example, if you define a 640x480 framebuffer/resolution in your config.txt, you canno't increase it to 800x600 by issuing this kind of command : fbset -xres 800 give you ioctl FBIOPUT_VSCREENINFO: Invalid argument while reducing framebuffer works : fbset -xres 600

Second trouble : Issuing a command to change color depth also give an error : fbset -depth 16 give the same invalid error ioctl FBIOPUT_VSCREENINFO: Invalid argument

Third error Pixel clock is not saved in the framebuffer information fbset -pixclock 1000 give no error but the value is not applied

Tested on a RPI4B, buster, firmware 4.19.88-v7l+

Those options were essentials when you wanted to change resolutions on the fly : #637

Thanks

[JamesH65]

I believe you should be using xrandr to change all those parameters when using FKMS or KMS. Or use the screen configuration utility from the preferences menu.

[ajefr]

I'm not using X11, only CLI...

[JamesH65]

Cannot remember the exact runes for doing it from the command line, but a quick fix would be to disable the KMS driver by commenting it out. That should force legacy mode, which has a real framebuffer. You lose 3d acceleration, but if you are on the command line, you are probably not interested in that anyway.

[ajefr]

Well, software I'm using requires the kms driver (retroarch / emulationstation). So if the kms driver could behave as the legacy driver, it would be perfect

[JamesH65]

I don't think it can behave the same. They are very different under the skin. I need to remember the runes for changing KMS driver resolution from the command line @6by9 Can you remember?

[6by9]

(Kernel issue, not firmware. This should really be under https://github.com/raspberrypi/linux/issues)

Looking at the drm_fb helpers, I don't see any handling for the switching resolutions. I do recall looking at this in the past though, and DRM ended up pulling in some drivers/video/fbdev in weird ways.

This is all mainline Linux code that provides the emulation. We can have a poke around to see if there is an easy win, but it really needs addressing in mainline. If there is an easy win then we may look to upstream those patches.

TBH All of this is really superceded by the KMS API, and clients wanting to change screen modes should be looking to use the newer API. That also provides a standardised way to provide your own mode timings, which is what raspberrypi/firmware#637 appears to be about.

[pelwell]

[ Moved to the linux repo ]

[lategoodbye]

Sorry for hijacking this issue. Currently the mainline development of the RPi 4 requires a Serial-USB-Adapter. So at least framebuffer support for Linux & U-Boot would be a big improvement. Since the guys from Igalia didn't show a motivation to touch the required low level driver (power domain, clock) we stuck at this point. It would be very helpful to get some pointers which downstream patches or at least which power domain & clocks are required for framebuffer support (just CLI).

[joolswills]

From my understanding kms mode switching has to be done on a per application basis. There's no way of just changing the framebuffer mode in a terminal and have that information passed to an app you run. (Different under x since all apps will run under that)

@psyke83 and @cmitu did some work on this for retropie so we have mode switching built into sdl2 and selectable from our app launcher (runcommand) for rpi4 + fkms.

See https://github.com/RetroPie/RetroPie-Setup/pull/2900

And

https://github.com/RetroPie/SDL-mirror/pull/16

[pelwell]

@lategoodbye If you have a specific feature request, can you open a separate issue?

[lategoodbye]

@pelwell No, i'm fine this this comment.