Drivers
LVGL's Linux drivers come in two kinds: display drivers that put pixels on a screen, and input drivers that read touch, mouse and keyboard events. Most setups need one of each.
Overview
LVGL's Linux drivers come in two kinds, and most setups need one of each:
- Display drivers get rendered pixels onto a screen — or into a texture, or a file.
- Input drivers read touch, mouse and keyboard events.
Some display drivers bring their own input, so pairing is not always necessary. The tables below say which.
If you are not sure which display driver you want, start from Choosing a Display Driver, which picks one based on what your system already has.
Display Drivers
| Driver | Best for | Rotation | Hardware acceleration | Runtime resolution change | Input |
|---|---|---|---|---|---|
| fbdev | Minimal systems exposing only /dev/fb | Software | None | No | Pair separately |
| DRM | Production embedded targets | EGL backend only | EGL backend | EGL backend only | Pair separately |
| Wayland | Systems running a compositor | Yes, all backends | EGL or G2D backend | Yes | Built in |
| X11 | Development on an X desktop | None | None | Yes | Built in |
| GLFW | Development with an instant GL context | Hardware | OpenGL ES | No | Built in |
| OpenGL Driver | Embedding LVGL in your own GL application | Hardware | OpenGL ES | Manual | None — you own the window |
| EGL | The layer under the accelerated backends, and headless rendering | Hardware | OpenGL ES | Depends on the driver | Depends on the driver |
Each driver page carries a fuller Support table, including color formats, multiple-display support and the render mode.
SDL is documented elsewhere
The SDL driver is a perfectly good option on Linux and is often the quickest way to get a window during development. Because it is cross-platform it lives under Running on PC rather than here. Its draw unit is documented with the other draw units.
A note on EGL
EGL is not usually a driver you select. It is the OpenGL ES platform layer that the DRM, Wayland and SDL drivers use for their hardware-accelerated backends, so selecting one of those backends turns it on for you. You reach for the EGL page directly in two cases: custom platform integration, and off-screen rendering with no display server at all.
Input Drivers
| Driver | Best for | Discovery and hotplug | Full keyboard | Touch calibration | Find device by capability |
|---|---|---|---|---|---|
| evdev | The common case — a known touchscreen or mouse | Yes | No | Yes | No |
| libinput | Text entry, or devices needing quirks | No | Yes, via XKB | Not needed | Yes |
Use evdev unless you need real keyboard support — layouts and modifiers — or your device requires libinput's quirk handling. evdev is lighter and is the only one of the two with automatic device discovery and hotplug.
Pair an input driver with a display driver by attaching it to the display:
lv_indev_t * touch = lv_evdev_create(LV_INDEV_TYPE_POINTER, "/dev/input/event0");
lv_indev_set_display(touch, disp);Rendering
Drivers decide how a frame reaches the screen; draw units decide who rasterizes it. The two are chosen independently — see Draw Units and OpenGL Overview.
One consequence worth knowing before you start: on every GPU and compositor path the render mode is fixed by the driver rather than configurable, because something other than LVGL owns the buffers. Only the CPU-blit drivers — fbdev, X11 and SDL's software backend — let you choose it.
See Also
- Choosing a Display Driver - decision table
- Draw Units - who does the rasterizing
- OpenGL Overview - which drivers provide a GL context
- Dependency Management - how enabling a driver pulls in its libraries
- lv_port_linux - reference project with every driver preconfigured
Pages
Individual pages in this section.
Last updated on
OpenGL Overview
How LVGL's OpenGL support fits together on Linux: which display drivers create a context, which draw units render on the GPU, and how the two combine.
Linux Framebuffer
The Linux framebuffer (fbdev) driver renders LVGL into /dev/fb through the kernel's framebuffer interface, with no libraries and no display server required.