24bit framebuffer issues

[rvalles]

Using framebuffer_depth=24 in config.txt , there's graphical problems on X. 32bit is even worse.

As 16bit is horrid and the hardware can do 24bit, fixing this and making 24bit the default would make a huge difference.

[jojopi]

32bit works if you also add "framebuffer_ignore_alpha=1". I have not actually investigated it, but to me the corruption without this, and especially the corruption in 24bit packed-pixel mode, looks more like an X issue than framebuffer.

[rvalles]

The distro I'm using is raspbian.

tried 32bit with framebuffer_ignore_alpha=1. It looks less mangled than 24bit, but sometimes (not always, as my desktop bg, which is a photo, looks fine) the colors are off for unknown reasons, plus xterm with -fg orange -bg black doesn't show any text.

Interestingly, The same thing happens without X, with links2 -g (uses directfb)

These screenshots show the problem (via gimp and fbcat respectively). They look on my workstation the same way as the wrongness looked in the pi:
http://b.rvalles.net/unsorted/raspberrypi_iceweasel_32bit_wrongcolor.png
http://b.rvalles.net/unsorted/raspberrypi_nox_links2_32bit_wrongcolor.png

My first reaction would be to blame libpng or libjpeg, but both png and jpeg images display fine with "display" from imagemagick, so I have little idea what's going on.

[rvalles]

As somebody asked.

root@pi:~# /opt/vc/bin/vcgencmd version
Jun 13 2012 11:49:28
Copyright (c) 2012 Broadcom
version 319510 (release)

[GeerGuy]

Do the 24-bit and 32-bit modes still have issues? Is there a work around?

Does this issue also effect omxplayer?

Will this be addressed soon?

Seems pretty important if you plan on using RPi to play media.

[popcornmix]

I believe all if correct with framebuffer_ignore_alpha=1.
Video doesn't use the framebuffer, so it makes so odd what the depth of the framebuffer is. You can set the framebuffer to 8bpp, and your video will still be perfect.

[GeerGuy]

I will run some tests with a colorimeter to determine if the colors are accurate and the video is sent out with 0-255 levels.

[GeerGuy]

I tested these display settings with omxplayer on an HDTV. I measured the MP4 patterns with a colorimeter and compared them to a known reference.

I ignored the EDID from the display and set it to 1080p, 60Hz.

hdmi_group=2 DMT
hdmi_mode=82 1080p, 60Hz
framebuffer_depth=32
framebuffer_ignore_alpha=1

Results:
Levels limited to 16 and 235
Levels clearly wrong.

hdmi_group=1 CEA
hdmi_mode=16 1080p, 60Hz
framebuffer_depth=32
framebuffer_ignore_alpha=1

Results:
Levels limited to 16 and 235
Levels were close, but not perfect. Luminance was off a bit.

How can I get the MP4s to play with 0-255 levels?

[popcornmix]

Can you try adding
hdmi_pixel_encoding=1
to config.txt.
The options are:

HDMI_PIXEL_ENCODING_RGB_LIMITED = 1,
HDMI_PIXEL_ENCODING_RGB_FULL=2,
HDMI_PIXEL_ENCODING_YCbCr444_LIMITED=3,
HDMI_PIXEL_ENCODING_YCbCr444_FULL=4,

[edit: corrected to match current firmware]

Actually looking at code, DMT should always use RGB_FULL. Only CEA modes can be change with hdmi_pixel_encoding.

I'd be interested to know if CEA in RGB_FULL mode behaves the same as DMT.

Are you sure DMT is using 16-235 levels? (rather than just being wrong for some other reason)
The software does appear to be setting DMT to always use full range.

[GeerGuy]

I tested with the Black Clipping MP4 from the AVSHD709 patterns set. It flashes from 1-25 on a 0 background. When I display this same pattern with a device that is known to output 0-255, I can adjust the brightness to see below 16 levels. With the RPi, the pattern does not change from 16 down no matter how the brightness is adjusted.

It was the same with both modes that I tested, but with DMT I had to adjust the brightness ~15% more to make it match the CEA mode.

I will run the same tests tonight with both hdmi_pixel_encoding settings.

I also plan on running some tests on the patterns that I can generate with Python.

[GeerGuy]

All tests are being done with Pygame fills from the console to a fullscreen.

The display that I am using for the tests adjusts it's levels depending on the input, so after making sure that the display was set right, I am getting 0-255 levels with DMT, regardless of the hdmi_pixel_encoding setting.

With CEA there is no difference between hdmi_pixel_encoding=0 and hdmi_pixel_encoding=1, I always get 16-235 levels.

DMT gives pretty good results, very close to a reference pattern generator.

[popcornmix]

Supporting full range with CEA is optional, so I'm guessing your monitor doesn't support it.

So are you happy with DMT output, for both video and console output?

[GeerGuy]

DMT is good.

[popcornmix]

I believe framebuffer_depth=24 now works, and framebuffer_depth=32 works with framebuffer_ignore_alpha=1.

[peutipoix]

Hi,
I need to use framebuffer depth of 32bits, and since this change in both firmware and directfb's configs I experience wrong colors in directfb (r and b swapped like rvalles's snapshot above).
I'm not sure whether it is related to this issue, or if it's nothing related to the firmware but with directfb's config... please advice.

I want to play and render a video with gstreamer (eglglessink) and use directfb to add an overlay.
I modified eglglessink to open a window on dispmanx layer -128, so that the framebuffer (layer -127) is in front, and use a 32bpp framebuffer to support alpha channel and mask directfb's background.

I updated /boot/config.txt, and /etc/directfbrc in consequence, but still end with wrong colors in directfb (video output from gstreamer is correct).

/boot/config.txt
framebuffer_width=1920
framebuffer_height=1080
framebuffer_depth=32
framebuffer_ignore_alpha=1
hdmi_pixel_encoding=1

/etc/directfbrc
mode=1920x1080
depth=32
pixelformat=ARGB

/opt/vc/bin/vcgencmd version
Jul 5 2013 15:46:59
Copyright (c) 2012 Broadcom
version ca0aa2db225d02577fc02e3c576fd2ae9975133b (clean) (release)

[popcornmix]

I've just started x with 16, 24 and 32 bpp, and each time the colours were correct.

I have a suspicion that directfb doesn't query the kernel fb driver for the RGB order. E.g.
https://github.com/raspberrypi/linux/blob/rpi-3.6.y/drivers/video/bcm2708_fb.c#L124

    $ fbset

    mode "1872x1056"
        geometry 1872 1056 1872 1056 32
        timings 0 0 0 0 0 0 0
        rgba 8/0,8/8,8/16,8/24
    endmode

and just assumes the wrong order.

[peutipoix]

Thanks a lot :) I can see now why the red and blue colors are swapped...

directfb-1.2.10.0 systems/fbdev/fbdev.c : 1774

dfb_fbdev_mode_to_var()
      case DSPF_ARGB:
      case DSPF_AiRGB:
           var.transp.length = 8;
           var.red.length    = 8;
           var.green.length  = 8;
           var.blue.length   = 8;
           var.transp.offset = 24;
           var.red.offset    = 16;
           var.green.offset  = 8;
           var.blue.offset   = 0;
           break;

bcm2708_fb.c#L124

if (ret == 0 && var->bits_per_pixel >= 24) {
var->red.offset = 0;
var->green.offset = var->red.offset + var->red.length;
var->blue.offset = var->green.offset + var->green.length;
var->transp.offset = var->blue.offset + var->blue.length;

Do you know the reason why directfb assigns the RGBA offsets such a way (BGRA)?

[popcornmix]

It's a bug?

They should query ioctl(fh, FBIOGET_VSCREENINFO, &var) to get the offsets not hardcode them. See:

http://git.busybox.net/busybox/plain/util-linux/fbset.c?h=1_6_stable