fbset is broken on RPi4

[alphanu1]

Fbset only works with 32 bit depth. Also then trying to change the FB size you end up with a an oversized image only viewing a small portion with large black bars between each pixel. or you do not have the large black bars but only see a small percentage of the screen.

It seem that actual video resolution does not change but the frame buffer is this could be linked to the tvservice issue #1206

I'll upload a pictures later.

[6by9]

Pi4 is loading the vc4-fkms-v3d overlay by default, so all the framebuffer support is an emulation on top of DRM/KMS. That is all standard Linux kernel code with no changes made for the Pi.

[alphanu1]

These issues are with vc4-fkma-v3d disabled

[JamesH65]

Rather a vital bit of information that was missing from the bug report...anything esle unusual about your configuration?

[alphanu1]

The following are other options in my config text. With other models of RPi fbset worked without issues with these settings.

dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1

[giddyhup]

fbset is also broken for other RPIs and older distributions (#1200).

[JamesH65]

C&P comment from #1200.

Just been looking at this with the latest firmware, Pi3B+, single composite display. With vc4-fkms-v3d enabled, fbset doesn't work as before. This, I believe, is expected. The vc4 driver (DRM/KMS) emulates a framebuffer rather than actually being a framebuffer, so fbset doesn't have the same feature set as if it were a real framebuffer.

If you disable vc4-fkms-v3d, then fbset works as expected, I was able to power off composite, power it back on and create a new FB with fbset. I did need to fbset -depth 8; fbset -depth 32 as before.

Since the DRM code that emulates the framebuffer is all uptream code I don't think there is much we can do about it. If you don't need the vc4 driver on the older devices (<Pi4), then just turn it off.

[giddyhup]

Thanks for the remark. I don't think it's enabled, I don't have dtoverlay=vc4-kms-v3d in /boot/config.txt.

This is my whole config.txt on the Pi in question:

enable_tvout=1
sdtv_mode=2
sdtv_aspect=1
overscan_left=-8

[JamesH65]

The only difference to my tests is I think the overscan option. WIll try that out on Monday.

[giddyhup]

For me it happens with or without overscan.

[JamesH65]

OK, so not sure then. It works for me here with the latest firmware. I presume you have tried rpi-update?

I see that you are using the VGA adapter. I can try and find one of those to test with - my tests were done with a composite display.

[JamesH65]

Just realised we are conflating two different reports here. @alphanu1 is using a VGA display attached via DPI, whereas @giddyhup seems to be using a composite display. This thread started of as a VGA/DPI thread, so that is what I am looking at.

I was not able to get the VGA display I have here up and running with the settings above - removing the hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1 line and it does get an image, 640x480.

If I am at the console (no X desktop running) with vc4_fkms disabled, then fbset works as expected, I can change resolution and colour depth.

If I am running X then fbset results in a blank screen. I believe this is as expected - you are pulling the rug out from underneath X and it doesn't know that the framebuffer has moved. Exit X, do the fbset changes, then reenter X.

So, in effect everything is working as expected.

[JamesH65]

Closing this issue as questions answered/issue resolved.

[alphanu1]

@JamesH65 What method are you using to change the resolution? I just want to check that I am not missing something!

[JamesH65]

IIRC, fbset -xres x -yres y