config.txt: Add "framebuffer_depth=32"

[gvolt]

Add "framebuffer_depth=32" when creating the config.txt file.

Without this option the default framebuffer depth of 16 leads to color banding. I noticed that for the background images and the pulsing webradio circle on an original 7" raspberry touch screen. Setting framebuffer depth to 32 resolved this.

Also some trailing spaces have been removed.

[volumio]

Will this affect only Raspberry PI display? Do you thnk there might be side effects? Look like this needs to be carefully tested

[gvolt]

I can only test on the Raspberry Pi display but would think other displays could be affected as well as the framebuffer_depth determines the number of colors that can be displayed. So I would expect a 32 bit picture (what typically means 24 bits are used for the three color channels, and the remaining 8 bits are the alpha channel or unused) to be affected by blanding on all screens (physically) connected to the Raspi if framebuffer_depth is lower than 32 (or least 24 if you relax the alpha channel).

On the RasPi I did not discover any issues so far. I did not notice any loss in performance (RasPi 3 B).

[volumio]

Why is 32 bit not default? Maybe there is a reason we don't know

[gvolt]

It could be because of speed and memory reasons as pointed out in this thread . As I said on my Pi 3 B I did not recognize a slow down of the UI or the whole system.

Also 6 years ago setting framebuffer_depth to 24 had issues. Setting to 32 seamingly lead to wrong colors back then but that was worked around by adding "framebuffer_ignore_alpha=1". As far I did not find the need to use that.

[gvolt]

Hm, this and this reads to me as if the default settings have already been changed to "framebuffer_depth=32" and "framebuffer_ignore_alpha=1" but have not been documented yet(?)

These new defaults might not have been set when Jessie was released.

[volumio]

So this is not necessary? In any case I am reluctant to merge as we need wide testing

[gvolt]

For Volumio "framebuffer_depth=32" is necessary. I did not find the need for "framebuffer_ignore_alpha=1". According to my last comment both settings seem to be the new defaults. But Volumio has "framebuffer_depth=16" as default. So I would probably set both "framebuffer_depth" to 32 and "framebuffer_ignore_alpha" 1" to replicate the seemingly new defaults.

My expectation would be that using these values would not prevent a system from booting but at worst lead to color issues and maybe slight slow down. I did not see any negative impact.

[volumio]

Sorry, I don't get it. We don't have framebuffer_depth=16 as default.

This is what we have
initramfs volumio.initrd
gpu_mem=16
max_usb_current=1
dtparam=audio=on
audio_pwm_mode=2
dtparam=i2c_arm=on
disable_splash=1
hdmi_force_hotplug=1

Or maybe I am missing something

[gvolt]

Sorry for not being clear.

With default setting I did not mean the content of the config.txt but the values that are used by the OS when nothing is specified in the config.txt.

I assume e.g. framebuffer depth must be predetermined somewhere "in the OS" in case the config.txt contains no value for it (like it is the case for Volumio ;) ). I see the config.txt as a possibility to easily set values for certain parameters that need to be different from the values given by the OS (= default values).

My conclusion from the links I posted above was that these (OS given) default values might already have been changed to "framebuffer_depth=32" and "framebuffer_ignore_alpha=1" in newer (EDIT: framebuffer_depth=32 is the new default since mid 2016) Raspbian releases.

Hope this clears up a little what I meant.

[xipmix]

dumb question - how did you determine framebuffer_depth = 16 ? I would like to provide confirmation of the issue (or not). I happen to have a pi2 and pi3.

[gvolt]

@xipmix: cat /sys/class/graphics/fb0/bits_per_pixel

The difference between 16 and 32 bit is most prominent e.g. on the "Darkness" background or the inner field of the pulsing webradio circle.

[xipmix]

Thanks for that, yep I have 16bpp. But I misunderstood your problem. I don't actually have a display shield, so can't test your issue - unless I am missing something. I do have a monitor hooked up but after the splash screen I get just the regular text console displayed.

[gvolt]

Yes, I have the original Raspberry 7" touchscreen connected and the touch display plugin installed. It would be interesting if the banding is visible on another screen/monitor connected via HDMI, too.

P.S. I think I found the file (bcm2708_fb.c) where the (OS) default is set in the raspberrypi sources on github. If you look at line 57 the value for "fbdepth" is set to 32.

[gvolt]

Could it be Volumio still uses this bcm2708_FB.c from the pi-kernel repo? This would explain why we have framebuffer_depth = 16 (see line 54) ;)

[macmpi]

With gpu_mem=16, it boots with start_cd.elf (cut-down) and not start_x.elf (extended) nor regular start.elf.
Maybe default for start_x may have changed to 32b, but not for start_cd ?

[gvolt]

Yep, that's it. I set gpu_mem=32, removed framebuffer_depth=32 and rebooted. Now cat /sys/class/graphics/fb0/bits_per_pixel issues 32 :)

So, does it make more sense to change gpu_mem to 32 than setting framebuffer_depth?

[volumio]

Yes, it seems to me that the most sound thing to do is set gpu_mem=32 .

[gvolt]

@volumio
Do you plan to change the config.txt accordingly (or would this be left to the user)?

[volumio]

Done with e3664ef

[macmpi]

Just one thing on consuming more CPU memory on all devices by default: Volumio is greatly designed as a lightweight distribution that runs nicely on tiny devices with fairly limited RAM (i.e. PiZero that make a perfect fit for embedding into Stereo systems, etc). This has great value.

Are we "just" talking 16MB less on CPU (which may still have impact on low spec devices), or has this change some other under-the-hood impact in terms of memory consumption (start.elf have different features/options enabled, so impact could be higher than those extra 16MB given to GPU).
Maybe doing a bit of benchmarking to measure CPU memory impact would make sense.

Also if this makes sense only for onscreen-setup (color banding), that could be changed if one install/activate relevant plugin (such plugins may tweak other stuff in config.txt), rather than have headless setups unnecessarily impacted.

Thoughts?

[chsims1]

I'd second macmpi's reservations about potential effects on devices such as RPi0. It makes more sense to me to only alter gpu_mem for those cases where it is necessary ie. in the display plugin.

[volumio]

While I tend to agree that we should add gpu memory only when installing display plugin, this is very hard to achieve unless we have some userspace utilitities which allow it to do it.
For rpi0 IMHO 16MB of RAM would not make much difference

[macmpi]

Isn't plugin's install.sh executed under sudo ?
I guess some smart sed regexp can probably take care of that decently enough.