/dev/fb0 disappeared

[oxoocoffee]

/dev/fb0 disappeared

[MichaIng]

Ah yes, if KMS is not enabled, /dev/fb0 is of course available. What I mean is that other than with the old kernel (on RPi 3), when KMS is enabled, /dev/fb0 is not available anymore. But do I understand that it is now the same on your RPi 3? Did you migrate to the new kernel/firmware packages with out script on the RPi 3?

When you select esp01215e and then select again none, there should really nothing be different, other than the framebuffer_width and framebuffer_height settings, which both, like the other 5 settings, should not have any effect anyway, when KMS is enabled (you select vc4-kms-v3d). Check/compare /boot/config.txt before and afterwards. So I am quite sure that it is not related to the missing display output.

Btw, did you reboot after selecting vc4-kms-v3d? Because this is much more likely the reason, as this in fact means a change. Try to select another resolution, or manually comment the dtoverlay=vc4-kms-v3d line in /boot/config.txt and reboot, then /dev/fb0 should be present again, and likely you have output again.

Probably the system has issues to auto-detect the native/supported resolution for this HDMI screen via KMS and selects one that it does not support. If this is a 1024x600 display, try to follow the docs I linked and add the following to the end of the line in /boot/cmdline.txt:

video=HDMI-A-1:1024x600M@60

This is for the HDMI0 port. For the other one, it would be HDMI-A-2.

But it could be also a different issue. Also check for kernel errors:

dmesg -l 0,1,2,3

[MichaIng]

As I mentioned in the other issue: With the new kernel/firmware packages, which are required for RPi 5, the legacy framebuffer driver is not supported anymore, hence I do not wonder that /dev/fb0 does not exist, but software needs to use DRI directly.

Also, not that, as also mentioned on our download page, some display settings hence do not work anymore, and they need to be reworked. The framebuffer_* and hdmi_* config.txt settings, which are used for esp01215e are affected in particular, hence enabling/disabling this LCD option should not have any effect.

There is a none option indeed which resets LCD-specific HDMI settings and in case removes added overlays (not the case for esp01215e). Hence output should be on HDMI with automatic or EDID-based resolution.

Please see the RPi docs about how to change resolution and orientation when KMS/DRM is used via kernel command-line arguments (/boot/cmdline.txt): https://www.raspberrypi.com/documentation/computers/configuration.html#setting-the-kms-display-mode
This is what I want to implement to dietpi-config. Bonus is that it works on most other SBCs and x86 the same way, as they mostly use KMS nowadays.

[oxoocoffee]

@MichaIng

• Just a bit of clarification about your comment hence I do not wonder that /dev/fb0 does not exist. After booting from a clear image and completing the setup process (no desktop installation selected), on a reboot /dev/fb0 is there.

• It seems that when I initially selected Display Options / LCD/OLED Panel addon / esp01215e followed by a reboot, which did not do what I expected, I decided to "revert". In the Display Options / LCD/OLED Panel addon / there is only uninstall, which is what I thought it would revert to before the change. This is where things did go wrong.
  On the next reboot, I could not see console/tty which makes sense because /dev/fb0 was not available at that moment.

• I shut down this time and pulled off the power to do a cold boot. Still a black screen.
  But in both cases above I could ssh to the unit. The only thing is I copied the config.txt backup file over /boot/ and rebooted.

• That did bring a console login prompt. So it looked like config.txt file was wrong until I copied the backup over it and rebooted.

• As far as There is a none option indeed which resets, Yes there is with aUninstall all panels. On my rp3 and rp5 with the latest 9.3, both are affected and I end up with a blank screen on boot and no /dev/fb0.

• Thank you for the rPI link. I will credit later on and see if I noticed something worth trying.

I also got a bit more information to look into #7029 ticket which I will update soon with my findings till now.

Cheers,

[oxoocoffee]

• I always reboot after changing config.txt :)
• Right now I have vc4-kms-v3d enabled in /boot/config.txt. I only changed it a couple of days ago to vc4-fkms-v3d. Nothing improvements.
• I just changed to 1920x1080 in dietpi-config \ Display Options \ 1920x1080 3rd option on my system from the top after vc4-fkms-v3d. After reboot, my sample worked in 16bit and 32bit. 32bit has a different issue with colors. But at least it is running.
• So, it must be a bug or limitation in vc4-kms-v3d and 32bit modes
• Here is the output after running my buggy test (leaves the terminal in yellow color). But when I run fbset -i to get the current state, I get the following. Please see 32 at the end of geometry

mode "1920x1080"
    geometry 1920 1080 1920 1080 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

Frame buffer device information:
    Name        : BCM2708 FB
    Address     : 0x3f800000
    Size        : 4147200
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 3840
    Accelerator : No

When you select esp01215e and then select again none, there should really nothing be different, other than the framebuffer_width and framebuffer_height settings,

• If I revert to vc4-kms-v3d using diet-config and reboot. Should framebuffer_width/height be uncommented out? Mine is uncommented and set to 1920x1080. What option in dietpi-config is responsible for commenting out/in frame buffer WxH parameters?
• Next, I removed esp01215e using dietpi-config and rebooted, as I initially reported. This time after a reboot /dev/fb0, does exist. Hmm.
• Next, I commented out framebuffer WxH in config.txt and rebooted. Hmm, I am not sure to tell the truth how to reproduce it. But I will keep trying.
• Next, with KMS driver loaded, should framebuffer_*be commented out? Or leave it uncommented.
• Next, I added video=HDMI-A-1:1024x600M@60 with framebuffer_* commented out and rebooted. fbset -i still shows 1920x1080x16.
• sudo dmesg -l 0,1,2,3 did not produce any output

Going to read the link you send me earlier now. More to come.

[oxoocoffee]

So far I was not able to reproduce it for whatever reason. I will close it and re-open it when I have more information.

[MichaIng]

So you mean the LCD does not show output as expected? What are your settings now, in case?

I am not sure whether fbset -i shows relevant output, when KMS/DRM is used. AFAIK, either /dev/fb0 (framebuffer device) is used, or /dev/dri/card0 (DRM), but not both. So it is possible that fbset -i shows the configuration for the case when KMS/DRM is disabled/the framebuffer is used, while the actual mode is different when KMS/DRM is used.

framebuffer_* settings in /boot/config.txt do not have any effect on KMS/DRM, especially not on RPi 5. They are marked as legacy in RPi docs, so I am not even sure whether they have any effect on RPi 5, even when having KMS/DRM disabled. Needs testing.