⬆️ Upgrade LVGL to 5.3

[HotelCalifornia]

Summary:

Upgrades LVGL to 5.3 release

Motivation:

everyone reeeealllly wants this

References (optional):

Should unblock #110 and by extension purduesigbots/liblvgl#13
Closes #92

Test Plan:

• let people play with it i guess

[HotelCalifornia]

everything compiles right now, but important things (namely LLEMU) appear to be broken.

[HotelCalifornia]

example of breakage:

[HotelCalifornia]

attached is a kernel template built on commit bd6bb46 for anyone who's interested in helping debug (e.g. @Jerrylum)
kernel@3.1.7-commit.13.bd6bb46.zip

[HotelCalifornia]

Ah, yes. One of the things we get in this upgrade is support for monospaced fonts, which I believe I set as the default. You should be able to switch back to the old (not monospaced) font with a call to lv_set_font or whatever it is (can't remember off the top of my head)

[HotelCalifornia]

the symbol should be lv_font_dejavu_20 (changing the number for the size you'd like). Monosapced fonts can be used with pros_font_dejavu_mono_20 and friends.

[Jerrylum]

OIC

https://github.com/purduesigbots/pros/blob/feature/upgrade-lvgl/include/display/lv_conf.h#L135

[Jerrylum]

I fixed the problem. That's fine right now.

[HotelCalifornia]

per @edjubuh:

For sake of backwards compatibility, I think the monospace should be turned on by default only when you initialize LLEMU

That's a good point. What I'll probably end up doing is just keeping the default font the same as it is, and changing LLEMU styles to explicitly use the monospaced version

[Jerrylum]

You can solve the problem by adding a delay at the first line of initialize function.

According Lines 43 - 45 in main.c file:
https://github.com/purduesigbots/pros/blob/develop/src/system/main.c#L43-L45
It is because the user 'initialize' function runs before the LVGL init and causes the problem. LVGL will display an empty screen (no object) in the init function, and it is grey. This keeps working in the old version, and I don't know why it is malfunctioning now.

I think we should be initializing LVGL before the system daemon, and the problem should be resolved.

[HotelCalifornia]

Thanks for the investigation, I'll give it a try at some point in the next few days or so.

You're right that we should probably be initializing LVGL before running the competition tasks... I'm not entirely sure why it was working before but it seems to have been a fluke.

[HotelCalifornia]

@Jerrylum thanks again for the help, changing the order of initialization does seem to have fixed it

[HotelCalifornia]

incidentally, now that we actually have a monospace font, we can finally impose a hard limit on the number of characters that can be printed on the LLEMU screen (33). this also means that we can get rid of the call to vasprintf (lol).

before:

after:

[HotelCalifornia]

I'm attaching a copy of the kernel from this PR (as of 890739f) so people can play around with it and tell me what's broken

kernel@3.1.7-pr144.629.zip

[HotelCalifornia]

well this is... uh... progress?

lv_obj_t* canvas;
static void* canvas_buf;
void initialize() {
	canvas = lv_canvas_create(lv_scr_act(), NULL);
	canvas_buf = malloc((lv_img_color_format_get_px_size(LV_IMG_CF_TRUE_COLOR) * 480 * 240)/ 8);
	lv_canvas_set_buffer(canvas, canvas_buf, 480, 240, LV_IMG_CF_TRUE_COLOR);
	lv_canvas_draw_circle(canvas, 240, 120, 60, lv_color_t{{0xFF,0xFF,0x00}}); // yellow
}

[jm-spencer]

I tested my screenlib on this, pretty much everything was the same.
The only exception is with text, which is printing slightly differently.

The text is printing a single 5x7 character on a 10x10 obj. If I remove everything except for aligning the label to the center of the cube, I get this branch printing 4 pixels right of the existing kernel.
Of course, it is possible this is a change with how aligning works or something with lvgl itself, I'll have to investigate more.

Existing kernel

This branch

[HotelCalifornia]

The only exception is with text, which is printing slightly differently.

What font were you using?

[jm-spencer]

This one here
If you’re planning on testing with it, know it only has the characters for numbers.

[HotelCalifornia]

Hm ok yeah. I'm pretty sure there were some changes made to the way that fonts are rendered (judging by the addition of support for monospace fonts). I wonder what would happen if you explicitly configured that font as such? See

pros/src/display/lv_fonts/pros_font_dejavu_mono_10.c

Line 5379 in 890739f

.monospace = 5, /*Fix width (0: if not used)*/

[theol0403]

First thing I noticed when I upgraded - my splashscreen image broke. Probably because the image was generated using the old convertor.

Before:


After:

Not much changed, it looks good. The only difference I noticed was under the angler page, in the button matrix on the left, the bottom button was expanded to fill the container. Most likely a bug fix.

I will get the image working, but apart from that the upgrade looks successful.

[HotelCalifornia]

Hmmm... The image thing alone might warrant bumping to 3.2.0

[theol0403]

I managed to get the image to work. However, it seems only True Color with Alpha gave me the results I needed, and it was a massive download.
Raw gave a "no data" error, and all the chroma-keyed ones had transparency problems.
Probably not a bug though, but it might be a good idea to suggest the best format in the docs.

[theol0403]

Working splashscreen with transparency.

I don't think I have anything else to test, aside from upgrading the image format, everything else worked properly.

@HotelCalifornia do you want me to try to use the canvas?

[HotelCalifornia]

I was also getting the "no data" thing when setting raw color format on a canvas. I think I saw something about needing a custom decoder for that.

That said, I had some ok results when using the indexed 8-bit format-- did you try that? Also I think @Jerrylum had some success with writing a bmp decoder that used 32-bit RGBA (which may actually be the same thing now I think about it)

[theol0403]

I did not try any indexed formats, but does it provide the transparency I need? My image is white, and the container background is orange, which is why the transparency is needed.

When I have time I will test the reading from SD card. Last time I tried I couldn't get it to work (it just gave no data no matter the path), and I needed to be able to compile LVGL on my own to enable the debugging options.

I know you have thought about it already, but I really think it is a good idea to provide LVGL as a template, which people can build on their own, and people can uninstall it and opt to install another template which contains the vexos screen wrappers.

[HotelCalifornia]

I did not try any indexed formats, but does it provide the transparency I need? My image is white, and the container background is orange, which is why the transparency is needed.

Ah, ok. Assuming that the 8-bit indexed format is actually RGBA, then yes, the "A" refers to an alpha (read: transparency) channel.

I know you have thought about it already, but I really think it is a good idea to provide LVGL as a template, which people can build on their own, and people can uninstall it and opt to install another template which contains the vexos screen wrappers.

Yeah I have thought about it. There are a couple problems:

• it's arguably better to have LVGL compiled in with the kernel:
  • so that it has a bit lower-level access (kernel heap, etc)
  • and requires basically zero configuration on the part of the user
• at this point removing LVGL from the kernel would be a really big breaking change

I suppose I could build a copy of the kernel with LVGL debugging turned on, if you think that would help

[Jerrylum]

I tested the LVGL Canvas feature and made a BMP image display function.
The function can display RGB (24 bit) .bmp and RGBA (32 bit) .bmp file.

This is the code:
https://gist.github.com/Jerrylum/5d4f3168a596dfbcd87e8d5f81236fcc

The result:

Showing "pros-icon-rgba.bmp", the picture is bigger then the screen

The image I used in the code:

• pros-icon.bmp (with white background, R8:G8:B8)
• pros-icon-rgba.bmp (with transparent background, A8:R8:G8:B8)

Size: 280px X 280px

Download:
images.zip

Tools to made image: Pixelformer

[baylessj]

Just a couple of minor polishing changes that I'd like to see, otherwise it seems ready to get merged.