Colors messed up on 32b LCD on standard button

Get started
1

This is a standard button. Drawn with this code…

LCD is 32b per pixel on a Linux system running framebuffer. This is using the fb object, not SDL.
Any idea will the colors are not the expected blue gradient?

I am compiled with this: LV_CFLAGS="-DLV_COLOR_DEPTH=32"
CPU is ARM Cortex-A7
I tried a lot of different variants, not produced the correct display.

scr = lv.obj()
btn = lv.btn(scr)
btn.align(lv.scr_act(), lv.ALIGN.CENTER, 0, 0)
label = lv.label(btn)
label.set_text(“Hello World!”)

Load the screen

lv.scr_load(scr)

3

(cc @amirgon)

4

Hi @Jon_Smirl!
I just tried the fb driver on my linux machine and colors seem fine:
image
To get this image I used fbgrab utility to capture /dev/tty1.

Here is the code I’m using to register the display driver and display the button:

# A simple test for Linux Frame Buffer
# Imports fb (frame buffer) module and uses it as lvgl display driver
# then show a button on screen.

import lvgl as lv
lv.init()
import fb
fb.init()

disp_buf1 = lv.disp_buf_t()
buf1_1 = bytes(480*10)
lv.disp_buf_init(disp_buf1,buf1_1, None, len(buf1_1)//4)
disp_drv = lv.disp_drv_t()
lv.disp_drv_init(disp_drv)
disp_drv.buffer = disp_buf1
disp_drv.flush_cb = fb.flush
disp_drv.hor_res = 480
disp_drv.ver_res = 320
lv.disp_drv_register(disp_drv)

scr = lv.obj()
btn = lv.btn(scr)
btn.align(lv.scr_act(), lv.ALIGN.CENTER, 0, 0)
label = lv.label(btn)
label.set_text("Button")

# Load the screen

lv.scr_load(scr)

while True:
   pass

lv_micropython (current master branch) is built for the unix port without any special flags:

make -C ports/unix -j4 DEBUG=1

So -

5

Same button appearance with your code. If I make red, green, blue rectangles they are correctly displayed. My guess - something in the gradient computation is not working right on ARM endian?

I will compile C program and give it a try.

6

Another idea: Could you run fbgrab on your ARM system?

If you can, you could run the same code on X86 and ARM, capture PNG files and compare them.
This could prove whether the problem is with the fb rendering driver, or with the linux display driver that outputs the frame buffer to your LCD.

7

Is it a big-endian system?

8

test2
test2.png480×854 2.31 KB

Looks like the framebuffer is fine. So something must be programmed wrong inside the LCD controller. This is dev board for a new CPU, so now I get to have fun poking through a couple hundred LCD register settings. People that wrote u-boot must have set something wrong.

I could not get fbgrab to work. So I copied /dev/fb0 to a file and then used ffmpeg on desktop…
ffmpeg -f rawvideo -pix_fmt bgra -s 480x854 -i test2.raw test2.png
Note that I had to flip argb to bgra to allow for endian difference.

9

Could this be related to the problem? Maybe your LCD expects little-endian and your buffer is big endian?
Could you try flipping endianness on /dev/fb0 and see if it makes it displayed correctly on your LCD?

10

We have located the error in the parameters being sent to LCD. Something to do with clocking it wrong. This was not a littlevgl problem.

1 Like