Xorg, configuring bpp (defaults to 16)

[Spider.007]

I installed Xorg with LXDE. By default it runs without any xorg.conf, but I noticed some colours weren't correct and I suspect that the bpp defaulting to 16 causes this. However, `man xorg.conf` states the default bpp is 24, so why would the RPi choose 16? Did I miss something, is this easy to configure or is the bpp not to blame?

[teh_orph]

The framebuffer on boot-up (which is what the console device is drawn on) is in 16-bit mode. X detects this and uses this mode. Even when changing the framebuffer mode to 24/32 bit for the console, I can't yet make X work on it.

EDIT: on the fixes to-do list

[jamesh]

Note that 16bpp will be faster....

[Spider.007]

The framebuffer on boot-up (which is what the console device is drawn on) is in 16-bit mode. X detects this and uses this mode. Even when changing the framebuffer mode to 24/32 bit for the console, I can't yet make X work on it.

EDIT: on the fixes to-do list

Yeah, I just noticed the same thing, and was looking for a way to change that. Thanks for the confirmation

Note that 16bpp will be faster....

Can you confirm that omxplayer actually runs in > 16 bpp? I was trying to compare that to Xorg, but omxplayer segfaults when you pass it a simple image

[felix123]

I get wrong colors when I use freerdp, would it be the same problem?



It's fine in rdesktop

[dom]

@felix123
What image/firmware are you running?
Try updating firmware to latest GitHub (Hexxeh's updater tool is one way). There has been a fix to RGB ordering in 32bpp mode.

[felix123]

I'm using the arch 29-04-12 image and I did a pacman -Syyu. I just did an update with Hexxeh's tool but the result is the same.

Also I notice if I drag the icons on the desktop around, then the correct color will show beneath the positions I drag.

[Spider.007]

I am pretty sure that those problems are not related to the RPi booting in 16 bpp

[jojopi]

The framebuffer on boot-up (which is what the console device is drawn on) is in 16-bit mode. X detects this and uses this mode. Even when changing the framebuffer mode to 24/32 bit for the console, I can't yet make X work on it.

It is very odd. "fbset -depth N" appears to work, but then Xorg switches back to 16 bits when it starts. "startx -- -depth N -fbbpp Z" switches the framebuffer into the requested mode, but either displays black or segfaults.

The following undocumented settings in config.txt do appear to work, however. This probably requires recent firmware:

Code: Select all

framebuffer_depth=32
framebuffer_ignore_alpha=1

[teh_orph]

I can only make it work if I start the fb console in 32-bit mode - changing at run time won't do it. Append to you kernel command line "bcm2708_fb.fbdepth=32" and reboot the system. Make sure you are using the new start.elf and have "framebuffer_ignore_alpha=1" in your config.txt.

Then start X, and it'll pick 32-bit mode. You won't need the -fbbpp option. No need for fbset.
X is not too much slower in 32-bit versus 16.

(this is what I'm doing in Arch with a hand-compiled git Xorg)

[spennig]

I can only make it work if I start the fb console in 32-bit mode - changing at run time won't do it. Append to you kernel command line "bcm2708_fb.fbdepth=32" and reboot the system. Make sure you are using the new start.elf and have "framebuffer_ignore_alpha=1" in your config.txt.

Then start X, and it'll pick 32-bit mode. You won't need the -fbbpp option. No need for fbset.
X is not too much slower in 32-bit versus 16.

(this is what I'm doing in Arch with a hand-compiled git Xorg)

Just using the undocumented config.txt settings

Code: Select all

framebuffer_depth=32
framebuffer_ignore_alpha=1

works fine for me in with the standard Arch X.org (I appreciate you may have been hacking it a bit), with contemporary start.elf.