default framebuffer depth changed to 32?

[joolswills]

Not sure this is a bug, but I can't find it documented anywhere - running Raspbian Lite.

Should the default framebuffer depth be 16 or 32 ? fbset reports it as 32 as of some recent kernel updates.

$ uname -a
Linux retropie 4.4.13-v7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux

$ fbset

mode "800x600"
    geometry 800 600 800 600 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

then updating via sudo apt-get update; sudo apt-get dist-upgrade

$ uname -a
Linux retropie 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux
$ fbset

mode "800x600"
    geometry 800 600 800 600 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

[popcornmix]

Yes. This is a deliberate change.
Some X composition routines are better optimised for 32 bit and the new Pixel desktop backgrounds look bettter.

[joolswills]

Thanks for the info - please could https://www.raspberrypi.org/documentation/configuration/config-txt.md be updated to reflect this?

Also I assume framebuffer_ignore_alpha is not required ?

[popcornmix]

framebuffer_ignore_alpha=1 is a default too do no need to change anything.

[joolswills]

Thanks. Will close this.

[macmpi]

@popcornmix can you please elaborate on this updated 32b framebuffer default in bcm2708_fb.c & relation to various firmware files start_cd.elf, start.elf & start_x.elf options? (and start_db)

For instance it seems system started with start_cd (triggered by gpu_mem=16 for instance) still reports 16b framebuffer by default: is that intended or a left-over?

[ab1jx]

Mine's argb (Raspbian) and 32 bit. I just wrote a Bresenham line drawing function writing 32 bits at once out and it flies with each pixel being a uint32_t. Couldn't do that with 24 bit color. I've seen 16bit, but only on an LCD that was limited to that by design.