framebuffer_depth=24 breaks X

[achrn]

If /boot/config.txt contains a line 'framebuffer_depth=24' then X will not run

To reproduce
Download 2020-02-13 buster
Add 'framebuffer_depth=24' to /boot/config.txt
boot

Expected behaviour
Should boot to a desktop.

Actual behaviour
Black screen with flashing cursor at top right
Pi is running, just X doesn't run
Alt-F1 gets to a command line and issuing 'startx' results in half a page of messages ending in a Fatal server error

/home/pi/.local/share/xorg/Xorg.0.log contains (towards the end)

[   676.567] (II) LoadModule: "fbturbo"
[   676.567] (II) Loading /usr/lib/xorg/modules/drivers/fbturbo_drv.so
[   676.567] (II) Module fbturbo: vendor="X.Org Foundation"
[   676.567]    compiled for 1.20.3, module version = 0.5.1
[   676.568]    Module class: X.Org Video Driver
[   676.568]    ABI class: X.Org Video Driver, version 24.0
[   676.568] (II) FBTURBO: driver for framebuffer: fbturbo
[   676.568] (WW) Falling back to old probe method for fbturbo
[   676.568] (II) Loading sub module "fbdevhw"
[   676.568] (II) LoadModule: "fbdevhw"
[   676.568] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[   676.568] (II) Module fbdevhw: vendor="X.Org Foundation"
[   676.568]    compiled for 1.20.4, module version = 0.0.2
[   676.568]    ABI class: X.Org Video Driver, version 24.0
[   676.569] (II) FBTURBO(0): using /dev/fb0
[   676.569] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[   676.569] (EE) FBTURBO(0): Specified fbbpp (24) is not a permitted value
[   676.569] (II) UnloadModule: "fbturbo"
[   676.569] (II) UnloadSubModule: "fbdevhw"
[   676.569] (EE) Screen(s) found, but none have a usable configuration.
[   676.569] (EE) 
Fatal server error:
[   676.569] (EE) no screens found(EE) 
[   676.569] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[   676.569] (EE) Please also check the log file at "/home/pi/.local/share/xorg/Xorg.0.log" for additional information.
[   676.569] (EE) 
[   676.589] (EE) Server terminated with error (1). Closing log file.

System

Raspberry Pi 3 Model B Plus Rev 1.3
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"

Raspberry Pi reference 2020-02-13
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 5f884374b6ac6e155330c58caa1fb7249b8badf1, stage4

Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
Revision : a020d3
Serial : 0000000070af2773
Model : Raspberry Pi 3 Model B Plus Rev 1.3
Throttled flag : throttled=0x0
Camera : supported=0 detected=0

[JamesH65]

Not taken a look at fbturbo code, but I suspect that it rejects 24 for performance and/or DMA reasons. 32bit frame buffers (and 16 to a lesser extent) are much faster and easier to handle as each pixel is aligned.

Why can you not use a 32bit or 16 bit buffer?

[achrn]

I can. I'm not demanding that framebuffer_depth=24 be made to work. What I want is a config option that used to work to not casue a black screen.
It used to accept 24 bit quite happily and all of a sudden has stopped working, casuing some considerable time to diagnose why a standard workflow setting up a pi for a standard application is now resulting in a black screen.
If the asnwer is that 24 bit is no longer supported that's fine, but in that case the documentation at https://www.raspberrypi.org/documentation/configuration/config-txt/video.md should stop listing it. It would be better if the system detected an option that causes a fatal error and didn't try and apply it.

[JamesH65]

We haven't changed FBTURBO recently AFAIK, so not sure why it has suddenly started objecting, I wonder if something was converting the 24 request to 32 internally before the FBTURBO was invoked and that conversion is no longer done. I suspect that 24 has never worked - would be interesting to know the framebuffer sizes on the previous release to see if it was actually 32bit (or 16)

[achrn]

I don't know what was happening internally, but Pis with framebuffer_depth=24 in /boot/config.txt most certainly used to boot and run a desktop with lots of colours happily. I have half-a-dozen digital signage deployments which have that, and was rolling out another five - I thought I'd update the underlying image while I was at it, and discovered that with my usual minimal changes to a clean image, the Pi didn't work.
2019-07-10 raspbian X does run with =24
2020-02-13 raspbian X does not run with =24
I don't know about any intermediate versions.

[JamesH65]

Can you do a 'vcgencmd dispmanx_list' on the working 24 version and post the output? That should tell us exactly what was created.

[achrn]

This is a 3B+:

Hardware	: BCM2835
Revision	: a020d3
Serial		: 000000008e2e708f

/etc/rpi-issue:

Raspberry Pi reference 2019-07-10
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 175dfb027ffabd4b8d5080097af0e51ed9a4a56c, stage4

tail of /boot/config.txt:

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d

# changes for digital signage deployment

# display orientation
display_hdmi_rotate=0

# colour depth
framebuffer_depth=24

the requested vcgencmd dispmanx_list:

display:2 format:XRGB8888 transform:0 layer:-127 1920x1080 src:0,0,1920,1080 dst:0,0,1920,1080 cost:1156 lbm:0 

Presumably '8888' means it is indeed in 32-bit.

[JamesH65]

I think that means 32 bit but alpha is ignored (xrgb rather than argb). I suspect that somewhere in the firmware, it used to convert to 32 from 24 but tht is no longer done. Will investigate Monday.

[achrn]

I expect this is expected, but for completeness: if the the 2019-07-10 raspbian is put through apt update; apt upgrade then it behaves the same as 2020-02-13 - boot to a black screen with flashing cursor at top left if framebuffer_depth=24 is in /boot/config.txt and boot to desktop fine if it's taken out.

[JamesH65]

A quick peek at the code and there are a couple of places where 24 is moved up to 32, but another couple of places where it isn't. Need to check with someone what our intended approach is here. Clearly the FBTURBO code cannot handle 24, so it's probably going to have to be expanded up to 32 in all cases.

[JamesH65]

Hmm. So what is happening here is actually now correct - what was happening before was a bit of a hack. Setting a framebuffer of 24 is actually working correctly when you go to the console. However, you cannot start X because the FBTURBO driver does not support 24. This is now correct behaviour, irrespective that it worked before (because of a hack). So I'm thinking this is now a wont fix, because actually, it's now working correctly on the Pi3. Pi4 is a slightly different kettle of fish - that's doing something really weird.

[JamesH65]

We've fixed a problem on the Pi4 with setting a 24bit framebuffer when in non-FKMS mode, but X will still fail to star as it does not support a 24bit framebuffer.

Since setting a 24bit framebuffer is a valid operation, it would be odd to revert to the old hacky code that in fact upped it to 32bits with no warning. So I don't think I'll be doing anything else on this - people can set a 24bit FB if they want and it will work on the console, but X will fail to start - the fix is to not set 24bit framebuffers in config.txt - use 16 or 32.

Closing as a Won't Fix.