Framebuffer is registered regardless of max_framebuffers=0

[MichaIng]

Describe the bug
The documentation states that setting max_framebuffers=0 in config.txt "will prevent any framebuffers from being allocated.". But regardless of this setting being set, during boot bcm2708_fb loads, finds the attached display and registers a framebuffer for it, resulting in /dev/fb0 being present.

To reproduce

echo 'max_framebuffers=0' >> /boot/config.txt
reboot
dmesg | grep bcm2708_fb
ls -l /dev/fb0

Expected behaviour
No framebuffer is registered.

Actual behaviour
A framebuffer is registered.

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

• Which model of Raspberry Pi? Raspberry Pi 2 Model B Rev 1.1
• Which OS and version (cat /etc/rpi-issue)? Debian Bullseye with official archive.raspberrypi.org firmware/kernel packages.
• Which firmware version (vcgencmd version)?

Nov 30 2020 22:14:05
Copyright (c) 2012 Broadcom
version ab1181cc0cb6df52bfae3b1d3fef0ce7c325166c (clean) (release) (start_cd)

• Which kernel version (uname -a)?

Linux micha.gnoedi.org 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020 armv7l GNU/Linux

Logs

root@micha:~# grep max_framebuffers /boot/config.txt
max_framebuffers=0
root@micha:~# dmesg | grep bcm2708_fb
[    0.000000] Kernel command line: coherent_pool=1M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=16 bcm2708_fb.fbheight=16 bcm2708_fb.fbdepth=8 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000  root=PARTUUID=907af7d0-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait net.ifnames=0 quiet loglevel=0 vt.global_cursor_default=0 snd_bcm2835.enable_hdmi=0
[    1.011706] bcm2708_fb soc:fb: FB found 1 display(s)
[    1.014545] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 16x16
root@micha:~# ls -al /dev/fb0
crw-rw---- 1 root video 29, 0 Dec  6 18:11 /dev/fb0

Additional context
I learned that config.txt settings value 0 actually means "default". In all cases I found so far, where 0 is a valid actual value, it is also the default, so aiming an actual value of zero and the default value matches, rendering the difference in the meaning of both irrelevant. I'm not sure now whether this is the first case where 0 is not the default value, but setting max_framebuffers=0 effectively only sets the default number of framebuffers, which might be 1?

[6by9]

You are quite right. I'll sort a firmware patch out.

[6by9]

Firmware patch is merged internally. It should be in the next rpi-update release.

[popcornmix]

@MichaIng please test latest rpi-update firmware and close if happy.

[MichaIng]

Many thanks, it works fine now. I guess those two error messages are expected then and cannot be muted when disabling framebuffers firmware-wise, right?

[    1.332206] bcm2708_fb soc:fb: Unable to determine number of FBs. Disabling driver.
[    1.332242] bcm2708_fb: probe of soc:fb failed with error -2

---

EDIT: Okay yes this all makes sense, quite similar to VCSM when loading cut-down firmware (<32 MiB GPU memory), as there is no device tree or kernel module load changes based on firmware config.

Similarly to disabling VCSM via device tree + kernel module blacklist, the RPi framebuffer device can be disabled via device tree now, without having simple-framebuffer as fallback automatically loaded. Previously, and without max_framebuffer=0, when disabling /soc/fb on headless system, the following happened:

[    1.302775] simple-framebuffer 3e330000.framebuffer: framebuffer at 0x3e330000, 0x8ca000 bytes, mapped to 0x(ptrval)
[    1.302797] simple-framebuffer 3e330000.framebuffer: format=a8r8g8b8, mode=1920x1200x32, linelength=7680
[    1.303473] Console: switching to colour frame buffer device 240x75
[    1.333195] simple-framebuffer 3e330000.framebuffer: fb0: simplefb registered!

Now, with max_framebuffer=0, this does not happen anymore. Interesting for perfectionists only, of course 😉.

---

I recognised as well now:

2021-01-10 21:21:59 root@micha:~# tvservice -s
state 0x120001 [TV is off]

without manually running tvservice -o. So max_framebuffer=0 has basically the same effect then (at least in combination with hdmi_ignore_hotplug=1)?