AnsweredAssumed Answered

32bpp -> 16bpp changing pixel information?

Question asked by Wouter Vanhauwaert on Nov 26, 2018
Latest reply on Dec 3, 2018 by Joan Xie

We are using a imx53 with kernel 2.6.35-maintain with following settings:



boot parameters: mxcdi0fb:RGB24,CUSTOM-1920x1080,bpp=32


static struct fb_videomode video_modes[] = {
/* 1920x1080 @ 60 Hz , pixel clk @ 148Mhz */
"CUSTOM-1920x1080", 60, 1920, 1080, 6734, 148, 88, 36, 4, 44, 5,


static struct mxc_fb_platform_data fb_data[] = {

.interface_pix_fmt = IPU_PIX_FMT_RGB24,
.mode_str = "CUSTOM-1920x1080",
.mode = video_modes,
.num_modes = ARRAY_SIZE(video_modes),


However, on continuous video stream playback , screens were blacking out after a while with IPU int errors. Turned out the IPU had difficulties keeping up. Changing boot parameters to mxcdi0fb:RGB16,CUSTOM-1920x1080,bpp=16 solved the video issue. So everything looked ok at that time.


However, we have a different hardware, having the previous output as an input, which really interpretes some colors on pixel level. Here we see, colors are not correct anymore. Even if we use only the upper 4 bits for interpretation. I would have assumed that going from 8 - 8 - 8 to 6 - 5 -6 would only drop the LSB's from the color, but that does not seem to be the case? Anyone knows how the conversion is done? And why is it rounding up pixel data?

Our application, generating this specific pixel data is running in a browser on X11 if that matters some way