The LVGL Visual Studio port gives you a Windows simulator with no extra dependencies

A pre-configured solution, not a tutorial

The repository is a Visual Studio project set up so that you can try LVGL on a Windows PC, and the README's own description is that it is a pre-configured Visual Studio project to try LVGL on a Windows PC. That framing matters because the alternative is wiring up an LVGL project, a display driver, a touch input driver and a build system by hand before you can see a widget. The dependency rule is unusually strict and is the reason the project builds cleanly on a bare machine. It only depends on the Win32 API, the C Runtime and the C++ STL, so you can compile it without any extra dependencies. The project is currently maintained using Visual Studio 2026, and the README is candid that it may well work without modification in Visual Studio 2022 version 17.13 or later but is not actively supported there, so it asks you to install and test with 2026 before reporting a bug.

Two modes with different display semantics

The port is split into a simulator mode and an application mode, and the difference is in how the display behaves. Simulator mode is designed for the LVGL simulation scenario, and it keeps the LVGL display resolution constant at all times, so that you can try out a UI layout the way it will appear on the production device rather than letting the host window dictate it. When the Windows DPI scaling setting changes, the Windows backend stretches the display content to compensate. Application mode is designed for Windows desktop application development, and it supports window resizing, with the LVGL display resolution changing to match, and the LVGL display DPI value changing as well when the Windows DPI scaling setting changes. Both modes share the same input story, with support for LVGL pointer, keypad and encoder devices, Windows touch input, Windows input method integration, and per-monitor DPI awareness in both V1 and V2.

Cloning with the submodules, in one or two steps

The repository contains other, necessary LVGL software repositories as git submodules, and the README is explicit that they are not pulled in by a normal clone and will be needed. There are two ways to get them. Everything at once clones the repository and all submodules in a single step:

git clone --recurse-submodules https://github.com/lvgl/lv_port_pc_visual_studio.git

Or you can do the main repository first and the submodules second, which is the path to take if you have already cloned:

git clone https://github.com/lvgl/lv_port_pc_visual_studio.git
cd lv_port_win_visual_studio
git submodule update --init --recursive

Keeping a clone current is also a two step operation, and the README explains why. The first step pulls in updates to the main repository, including updated references to the submodules, and the second updates the code in the submodules to match those references:

git pull
git submodule update --init --recursive

If you have forked the repository, updating from upstream takes a different and more involved procedure, which is the one thing the README does not script for you.

Building, running and switching demos

The build is a Visual Studio action rather than a command line. You open the `LVGL.slnx` solution file in Visual Studio, set the `LvglWindowsSimulator` project as the startup project, click the `Local Windows Debugger` button in the top toolbar, and the included project is built and run, launching from a cmd window. There is a list of possible test applications in the `LvglWindowsSimulator.cpp` file, and each test or demo is launched via a single function call. By default the `lv_demo_widgets` function is the one that runs, and you can comment that one out and choose any of the others. Demos outside the default two widgets, `lv_demo_widgets` and `lv_demo_benchmark`, are enabled by editing `lv_conf.h` in the DEMO USAGE section around line 1199 and setting the associated variable to 1 instead of 0, for example changing `#define LV_USE_DEMO_MUSIC 0` to `#define LV_USE_DEMO_MUSIC 1`.

Two known issues worth knowing before you file a bug

The known issues section is short and both entries are avoidable. The first is the `LV_MEM_SIZE` macro in `lv_conf.h`, which should be 128 KiB or larger because you may hit an out of memory issue with the 64-bit simulator, and the project sets it to 256 KiB. The second is a target selection trap. Users need to check the target selected in Visual Studio, because the simulator project supports ARM64 and Visual Studio will choose ARM64 the first time, on the alphabetical order of the platforms. If you are debugging on x64 and did not look at the target, the binary you are running may not be the one you meant to run. The repository also has a `BuildAllTargets.cmd` and a `BuildAllTargets.proj` at the root, plus a `global.json` and a `manifest.json`, which suggests the multi-target build is scripted rather than purely manual.

Versions, branches and the Visual Studio Code alternative

The version story has two parts and one caveat. If you want the stable version you use branches with the `release/` prefix, and the master branch is the current development version which may contain issues such as compilation failures, with the 2025 roadmap linked in an issue. If you need to use Visual Studio 2017, 2019, or 2022 before version 17.13, you should use the `release/v9.4/legacy-vs-solution` branch. The caveat is about submodule references. The repository updates its submodule references shortly after minor version updates, and a matching version tag is added after the release of new major releases of the LVGL core project, but if you need bug fixes from more recent changes in the submodules you will have to update the references yourself, and if source files were added or removed in the submodules the Visual Studio project will likely need adjusting. The commit log is offered as the guide for that, and `Documents/` holds the notes on synchronising the submodules and the default `lv_conf.h` configuration.

Why this is not the Visual Studio Code port

The first note in the README is a boundary, and it is worth repeating because the two projects are easy to confuse. If you want to use CMake based LVGL projects, you should use `lv_port_pc_vscode` in Visual Studio, since this repository is for MSBuild based LVGL projects, which suits traditional Visual Studio users rather than Code. The README is blunt about it in one line, this project is not for Visual Studio Code, it is for Visual Studio, and the Windows backend integration support for `lv_port_pc_vscode` is on the way, with a pull request linked for more information. The licence is MIT, the release history shows v9.0.0 in January 2024 and v9.2.2 in February 2025, the last push was on 2026-09-27, and the repository is not archived. The reason to reach for either port rather than a generic embedded toolchain is that LVGL's own configuration, its widget set and its layout rules are the things you are actually developing against.

Editorial conclusion

Adopt the LVGL Visual Studio port when you are writing an LVGL interface and want a fast feedback loop on a Windows desktop before flashing hardware, since the project compiles with no dependency beyond the platform libraries and ships a working solution and demo switcher. Do not adopt it if your project is CMake based or if you build in Visual Studio Code, because the README points both of those cases at the separate `lv_port_pc_vscode` repository. Verify first that you are on Visual Studio 2026, since the project is maintained with that version and earlier ones are only supported on the `release/v9.4/legacy-vs-solution` branch, and check the `lv_conf.h` memory setting before running the 64-bit simulator.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lvgl/lv_port_pc_visual_studio on GitHub
4. README
5. Releases