LVGL: the MIT-licensed C UI library for MCUs, and what LVGL Pro adds

What LVGL solves on a board with a screen

Bare-metal firmware with a display usually starts the same way: a framebuffer, a panel init sequence, and then a pile of drawing code that grows into a small windowing system nobody planned. LVGL is that windowing system, already written. It is a C library (C++ compatible) with no external dependencies, so it compiles for any modern target the toolchain supports, and the README states that a typical UI needs only about 100kB RAM, 200 to 300kB flash, and a render buffer of one tenth of the screen. The floor is lower still: at a bare minimum, 32kB RAM and 128kB flash, a frame buffer, and that same one tenth screen buffer.

The intended user is an embedded engineer who has a panel and a microcontroller, not a web developer with a browser. LVGL targets monochrome, ePaper, OLED and TFT displays, and the README notes that chip vendors including NXP, Espressif and Renesas, RTOS projects such as Zephyr and NuttX, and board makers including Riverdi, Seeed Studio, VIEWE and Elecrow have integrated it. That matters less as a popularity signal than as a practical one: if a board has a display, the vendor probably already ships an LVGL port, which is where you should look before writing display glue yourself.

The rendering model, widgets and layouts inside src

LVGL is a retained-mode widget library. You create objects (Button, Label, Slider, Chart, Keyboard, Meter, Arc, Table among 30 or more built-in widgets), set style properties on them, and LVGL redraws the regions that changed into the buffer you supply. The buffer does not have to be a full frame: the README describes rendering from a buffer of roughly one tenth of the screen, which is what keeps the RAM figure in the hundred-kilobyte range rather than the megabyte range.

Styling is separate from widget creation. There are more than 100 style properties covering parts of a widget in different states, and Flexbox and Grid-like layout engines position and size children automatically, so you do not hand-place every element for each screen size. Input is abstracted the same way: mouse, touchpad, keypad, keyboard, external buttons and encoder are all input devices, and multiple displays are supported in one application. Text is rendered as UTF-8, with CJK, Thai, Hindi, Arabic and Persian writing systems listed as supported.

The renderer itself is 2D and built in: shapes, gradients, anti-aliasing, opacity, smooth scrolling, box and drop shadows, image transformation. Vector graphics, SVG and Lottie are supported, and there is a 3D engine for glTF models with OpenGL. GPU acceleration exists for VG-Lite, Dave2D, NeoChrome and OpenGL, but the README is explicit that OS, external memory and GPU support are optional rather than required. The repository layout reflects that split: src/ holds the library, libs/ holds optional integrations, demos/ and examples/ hold reference material, and lv_conf_template.h is the configuration surface you copy and edit.

Installing LVGL and getting a first screen up

The README does not present a single canonical install command. It points instead at a Simulator project for PC-based development, the Online Viewer, and one-click simulator integration in LVGL Pro, and it notes that Make, CMake and simple globbing are all supported. What the repository does provide is the configuration template at the top level, lv_conf_template.h, which is the file you copy to lv_conf.h and edit before building. The README also states that the library has no external dependencies, so in the simplest case you add the sources to your build and include lvgl.h.

If your build is CMake-based, the top-level CMakeLists.txt is the entry point for adding the library as a subdirectory, and the repository also ships CMakePresets.json, which the project uses for its own build configurations. For ESP-IDF, idf_component.yml and Kconfig are present at the top level; for Zephyr, there is a zephyr/ directory; for PlatformIO, library.json; for Arduino, library.properties; for RT-Thread, SConscript and component.mk. Which of these you use depends on your toolchain, and the README points to the documentation site for the integration details rather than repeating them.

The README's own examples live under examples/, including examples/get_started/ and examples/porting/, and the project's documentation site is where the README sends you for the sequence that starts lv_init(), registers a display driver with a draw buffer, and calls the timer handler periodically. Expect the first build to fail on configuration rather than on missing code, because lv_conf.h controls which widgets, fonts and features are compiled in, and the RAM and flash figures depend on those choices.

Where LVGL is the wrong tool

The memory numbers are the honest constraint. A hundred kilobytes of RAM and a few hundred kilobytes of flash are fine on an STM32 or an ESP32, and they are not fine on a small 8-bit part with a few kilobytes total, where the README's own bare minimum of 32kB RAM and 128kB flash already exceeds the device. If your budget is below that floor, LVGL is not a candidate regardless of how good the widget set looks.

The second limit is scope. LVGL gives you widgets, styles and layouts, not a browser and not a document model. There is no HTML or CSS engine here, so a product whose UI is really a web page rendered on a panel is a different problem. The 3D engine depends on OpenGL, which the README lists among the optional GPU backends; on a target without a GPU, glTF rendering is not a realistic path.

The third limit is documentation shape. The README is a landing page: it links to the docs, the forum, the blog and the services page, and gives the feature inventory and the memory envelope. It does not document rollback, version migration, or what changed between v9.4.0, v9.5.0 and v9.6.0; for that you have to read the release notes. The repository ships tests/ and a gcovr.cfg, so the project measures its own coverage, but the README makes no claim about what that coverage is.

LVGL Pro, and how it differs from writing C by hand

LVGL Pro is not a replacement for the library. It is a separate toolchain that sits in front of it: an Editor desktop app for building screens and reusable components in XML, an Online Viewer at viewer.lvgl.io that runs the Editor in a browser, a Figma plugin that moves a design into LVGL Pro, and a CLI tool for generating C code and running tests in CI/CD. The README's claim is that it exports plain LVGL C code with no extra runtime or hidden magic, so the build and ship process does not change.

The honest comparison is against editing C directly. Hand-written LVGL is fast to start and slow to keep consistent as screens multiply, because layout, styling and data binding end up duplicated across files. The Pro path moves that into XML with data bindings, translations, animations and tests in one place, at the cost of a second tool in the pipeline and a generated-code step. The README states that Pro is free for non-commercial use and evaluation, which is a different licence position from the library itself: LVGL is MIT, Pro is not. If your project is commercial, that distinction is the first thing to check before building a workflow around the Editor.

If you want the alternative in the same category rather than a different product, it is LVGL without Pro: same library, same widgets, XML files replaced by C files you maintain yourself.

Maintenance, releases and licence position

The repository is not archived, and the last push was on 2026-09-19, two days before the date of writing. Releases are frequent and versioned: v9.4.0 on 2025-10-16, v9.5.0 on 2026-02-18, and v9.6.0 on 2026-09-16. A roughly six-month cadence between minor releases means an upgrade is a recurring cost, not a one-off, and the README does not describe a migration procedure. Budget for reading release notes and rebuilding before you move a shipping product across a minor version.

The upgrade cost is also configuration cost. Because features are compiled in through lv_conf.h and the memory figures depend on which widgets, fonts and renderer options you enable, a version bump can change your footprint even when your application code does not change. The repository ships lv_version.h.in and a sbom/ directory, which suggests the project tracks its own version and software bill of materials, but the README does not promise binary compatibility across minor releases.

On licensing, LVGL itself is MIT, which the README calls out as the reason it can be used in commercial projects. That is the library only. LVGL Pro is described as free for non-commercial use and evaluation, so the two are not covered by the same terms. This is a description of what the material says, not legal advice; read LICENCE.txt and COPYRIGHTS.md in the repository, and the Pro terms on the project's site, before shipping.

Editorial conclusion

Adopt LVGL when you are writing a C UI on a display-equipped MCU or MPU and want widgets, layouts and input handling without pulling in a graphics stack of your own; the MIT licence and the absence of external dependencies make it usable in closed commercial firmware. Skip it if your product needs a browser engine, a full desktop widget toolkit, or heavy 3D on hardware without a GPU, and skip LVGL Pro if your UI is a handful of static screens you can write by hand in an afternoon. Before committing, verify the RAM and flash floor against your own widget set, confirm that a display driver already exists for your panel and controller, and check lv_conf_template.h for the options your target needs.

Frequently asked questions

Official sources

1. License: MIT
2. lvgl/lvgl on GitHub
3. Project website
4. README
5. Releases