Important: Please read the Qt Code of Conduct -

Qt/Embedded on Framebuffer RGB666 / 32 bit depth

  • Hi everyone,

    I'm trying to deploy my Qt application on an embedded system based on the Marvell PXA320, using the Linux framebuffer. Its LCD controller supports a pixel depth of 32 bits, but the pixel format is 6 bits each of R, G and B, packed and aligned to the LSB. There is unfortunately no configuration where the colour components are aligned to byte boundaries, which would enable Qt embedded to support it out of the box.

    So for each pixel the framebuffer looks like this:
    MSB -> LSB
    (14 unused bits) R5 R4 R3 R2 R1 R0 G5 G4 G3 G2 G1 G0 B5 B4 B3 B2 B1 B0

    Qt reads the pixel depth and colour component lengths and offsets via the fb ioctl, but when the depth is 24 or 32 bits, it seems to simply assume a pixel layout whithout taking the lengths and offsets into account.

    I've browsed through the Qt source code and read lots of documentation. I think the actual pixel format conversion and copying to the framebuffer memory happens in qscreenlinuxfb_qws.cpp and qscreen_qws.cpp, but I might be wrong.

    I am willing to hack Qt to support this pixel format, but I need some hints where to start and what functions need to be looked at.

    Best regards,

  • Ok, I figured out I have to configure and compile Qt with "-depths generic" so it actually reads the colour component lengths and offset from the framebuffer device.

    Things are looking much better now, but there is still a problem:

    Although most of the desktop and windows seem fine, text is looking blurred with randomly coloured pixels around it. The window buttons have strangely coloured edges and any icon loaded from PNG files and rendered to the screen looks strange as well.

    To me it looks like some problem with alpha channel handling. Does anyone have a clue?

Log in to reply