LvglPkg - Exploring Modern Firmware User Interfaces with LVGL and EDK II

[hamitcan99]

Hello everyone,

I would like to share a project that I have been working on recently:

https://github.com/hamitcan99/LvglPkg

LvglPkg is an EDK II package that integrates the LVGL graphics library into the UEFI environment.

The project started as an experiment to investigate whether modern embedded UI frameworks could be used to build richer firmware user interfaces beyond the traditional SetupBrowser approach.

While EDK II already provides several mechanisms for building setup applications, most firmware interfaces today are still constrained by workflows and design concepts that have remained largely unchanged for many years. My goal was to explore what a modern firmware UI stack might look like when built on top of a widely adopted graphics framework.

Current work includes:

LVGL integration into EDK II
Graphics output backend implementation for UEFI
Input handling integration
LVGL application support within firmware
Experiments with modern firmware user interface concepts

As part of this effort, I have also been experimenting with an LVGL-based alternative to DisplayEngineDxe. The intention is not to replace existing EDK II solutions, but to explore whether a more flexible rendering and widget framework could simplify the development of richer firmware interfaces, especially on higher-resolution displays.

Some areas that I find particularly interesting are:

Modern BIOS/Setup user interface concepts
Responsive layouts for different display resolutions
Improved visual consistency across firmware applications
Reusable UI components and widgets
Alternative rendering architectures for firmware environments

The repository is still under active development and should be considered experimental. There are many areas that can be improved, and I would greatly appreciate feedback from the community regarding architecture, integration approaches, portability, performance considerations, and potential use cases.

Repository:

https://github.com/hamitcan99/LvglPkg

Feedback, suggestions, and contributions are welcome.

Thanks,

Hamit Can Karaca

[MarsDoge]

I agree with your experiment. I recently also tried developing a modern Setup graphical engine and a companion app to verify it.
My repository address is: https://github.com/MarsDoge/ModernSetupPkg. I think we can collaborate on this experiment.

[hamitcan99]

Hi @MarsDoge, thank you for sharing ModernSetupPkg. I spent some time going through the repository and I find the approach really interesting.

Your XArch model and the clean separation between the HII/FormBrowser ownership layer and the GOP rendering backend is exactly the kind of architectural discipline this space needs. The ModernDisplayEngineDxe / ModernUiEngineLib split is particularly well-thought-out, and the before/after DisplayEngine captures show the concept working end-to-end across ArmVirt, LoongArch, and OVMF X64.

LvglPkg is exploring a somewhat different angle: instead of building a custom renderer from scratch, I'm bringing LVGL into the UEFI environment to see whether its widget framework and rendering pipeline can serve as a foundation for richer firmware UI surfaces. Especially on higher-resolution displays where the traditional form browser layout starts to feel limited.

I think our work is complementary rather than overlapping. Your architecture already cleanly separates the DisplayEngine contract from the drawing backend, which is exactly the kind of integration boundary where an LVGL-backed renderer could plug in. There may also be value in comparing how we handle GOP flush timing, input event dispatching, and font rendering under UEFI constraints. Tthese are areas where I have run into real tradeoffs.

I would genuinely like to collaborate. If you are open to it, I can open an issue on your repository to start a more focused technical discussion, or feel free to do the same on LvglPkg. Looking forward to it.

[MarsDoge]

Hi @hamitcan99, thank you for the thoughtful response and for taking the time to look through ModernSetupPkg.

I agree that our projects are complementary, and I would be happy to collaborate.

Please feel free to open an issue in ModernSetupPkg so we can continue the discussion in a more focused place. I would be glad to exchange ideas and explore possible directions together. Looking forward to it.