Xorg, configuring bpp (defaults to 16)


11 posts
by Spider.007 » Sat May 19, 2012 2:18 pm
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?
Posts: 34
Joined: Sat May 19, 2012 11:24 am
by teh_orph » Tue May 22, 2012 9:32 pm
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 :)
User avatar
Posts: 345
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
by jamesh » Tue May 22, 2012 9:52 pm
Note that 16bpp will be faster....
Volunteer at the Raspberry Pi Foundation, helper at Picademy September, October, November 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12370
Joined: Sat Jul 30, 2011 7:41 pm
by Spider.007 » Wed May 23, 2012 7:32 am
teh_orph wrote: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 :)
jamesh wrote: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 ;)
Posts: 34
Joined: Sat May 19, 2012 11:24 am
by felix123 » Thu May 24, 2012 12:18 am
I get wrong colors when I use freerdp, would it be the same problem?
Image
Image

It's fine in rdesktop
Image
Image
Posts: 153
Joined: Tue May 15, 2012 6:06 am
by dom » Thu May 24, 2012 9:08 am
@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.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4105
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by felix123 » Fri May 25, 2012 1:52 am
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.
Image
Posts: 153
Joined: Tue May 15, 2012 6:06 am
by Spider.007 » Fri May 25, 2012 7:41 am
I am pretty sure that those problems are not related to the RPi booting in 16 bpp :)
Posts: 34
Joined: Sat May 19, 2012 11:24 am
by jojopi » Sat Jun 02, 2012 1:31 am
teh_orph wrote: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
User avatar
Posts: 2132
Joined: Tue Oct 11, 2011 8:38 pm
by teh_orph » Sun Jun 03, 2012 5:52 pm
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)
User avatar
Posts: 345
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
by spennig » Sun Jun 03, 2012 6:49 pm
teh_orph wrote: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.
User avatar
Posts: 84
Joined: Mon Aug 29, 2011 11:34 am
Location: New Forest