QT and image colors displayed on LCD Cape 7

Hi everyone,

i have a problem displaying 24 bit images (using QImage or QPixmap) on beaglebone on 7’’ LCD Cape (i’m using cross - compiled QT embedded 4.8.5).

The image appears with less colors and not clean (dithering problem?).

I did not understard where the problem is:

Does it depends on QT configuration (not properly compiled or configured), QT code (i assign the Qimage built from default constructor to QLabel) , linux framebuffer driver,

LCD Cape (i don’t think because i tried to display with Angstron on X11 ant the image is perfect) ?

I hope someone can address me to figure out the problem .

Please find attache the original image.

Thank you.

circle12.zip (44.1 KB)

LCD7 is 16 bit color.


It is most likely because LCD 7" cape overlay only enables 16bit color. Thats why you are losing color depth.

no it’s not :wink:


==> Interface RGB 24bit

Ah, so the missing 8 bits are transmitted wireless ?

-- Bas

Yes the LCD itself is capable of 24bit color but the BBB only interfaces with 16bit color.

I’m just saying that the LCD is 24 bit, that’s all !

It is 16 bits. I know the designer very well. Look at the schematic.



  • LCD_DATA[0…15] <–16bit

So. If the signals are not connected it is being used as a 16 bit display because that is all that is connected from the processor. 16bits.


You are surely right, I’m just reading the general specification at page 4/29 of the documentation : http://elinux.org/images/d/dc/TFC-S9700RTWV35TR-01B.pdf

and this page http://elinux.org/CircuitCo:BeagleBone_xM_LCD7 said RGB 24b (same lcd board )

Not my fault if they are wrong …

The schematic rules. I designed the board. Somebody else wrote the manual.


I think, we are both right, I’m talking about the LCD, you are talking about the LCD Cap.

The documentation, I was talking is from the constructor of the LCD( ThreeFive ) :


and it said 24 bit. I can verify that because on this schematic, the data is 3*8 bit :


To summarize, yes it’s a 16 bit LCD cap, because you designed it like that.


Correct. Yes, the LCD supports 24 bits, but only 16 can be driven. We have 16 Bits on the HDMI as well.

But if you drive this display as a 24 bit display, you will get what you are seeing because the signal assignment from the processor changes between 16 bit and 24 bit mode. We are using a true16b mode from the processor, Not 24…



Thank everyone,

i suppose i have to use 16 bit images.