Linux Wayland Support

I’m working on creating a GUI with LVGL on an iMX8 based platform. Supposedly, direct framebuffer manipulation is discouraged and recommends writing/reading to a compositor such as Wayland/EGL. (See IMX_GRAPHICS_USERS_GUIDE.pdf)

Lup Yuen Lee has created a display port to use EGL to render the screen, but I’m still having some issues getting it built at the moment. (I think due to old EGL libraries calling for X11 headers)


I figured I would add this request for official support now.

Someone recently contributed a Wayland driver, though we haven’t really tested it much yet. Have you given it a try?

1 Like

Wow, I didn’t notice this! I’ll give it a try.

I tried this and the basic example works (LVGL version 8). Is it possible with Wayland, that one writes a transparent canvas to an existing framebuffer, which is already written by a GPU thread (OpenGL with Wayland EGL) outside of LVGL? I guess it should theoretically work, because Wayland uses DRM. (?)

If you can get back the buffer rendered by the GPU it can be used as a canvas (or image) for LVGL. But probably you should use 2 buffer because if the GPU draws asynchronously LVGL might display a half-ready image.

So you are saying it is possible, that those are totally independent threads (one GPU thread writes to the hardware framebuffer and one LVGL-CPU thread writes independently to the hardware framebuffer) and I can just overwrite/diff the hardware buffer by writing a transparent canvas on top of it ? As far as I understood, that is the advantage of DRM, that several processes can access the same hardware framebuffer without producing race conditions.

Maybe I misunderstand it. Do want to write the same framebuffer with LVGL and GPU too?
If so it’s highly discouraged if the GPU operations are not managed by LVGL. Else the GPU and LVGL won’t be synchronized and overwrite each other’s data.

Yes, the same hardware framebuffer, but with LVGL I only want to write like every 50ms and also “just” a canvas with transparent background on top of the already existing GPU written buffer. You are most probably right, that there will be synchronization problems, nevertheless.
Alternative would be to use GPU accelerated wayland LVGL driver for everything.

Also there should be used a mutex for the “hardware framebuffer” access between the threads. Not sure, how I would use a mutex between GPU and CPU threads, though.

It sounds like it would be best to have LVGL render to an in-memory bitmap and then use the GPU to blit that bitmap to the final buffer, in that case.

1 Like

Thank you for the tipp, so do I have to write an own dummy flush_cb or are there simpler ways ?

This is also in the same direction :

? Seems to be planned to be addressed in 8.1.

That issue is slightly different - it covers LVGL using the GPU to accelerate its own rendering, but in that case LVGL still expects to control the full screen.

You would have to write your own flush_cb which renders to a buffer, which the GPU can later blit to the real framebuffer.


Thanks. Sounds reasonable.

Related activities:

I am about to test this on yocto using WIP recipes: