# u8g2: the monochrome graphics library most Arduino displays run on > A single C library spanning dozens of monochrome OLED and LCD controllers, shipped as a buffered full-graphics variant and a no-buffer text variant, with the real documentation living in a wiki rather than the README. **olikraus/u8g2** — U8glib library for monochrome displays, version 2 - Repository: https://github.com/olikraus/u8g2 - Stars: 6,711 · Forks: 1,228 - Language: C - License: NOASSERTION - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/olikraus-u8g2 ## One library covering a long list of monochrome controllers The pitch is breadth. The README names SSD1306, SSD1309, SH1106, ST7565, UC1608, T6963, PCD8544, KS0108, IL3820 and a long tail of others, all driven through one drawing API. That list is the reason the project has roughly 6,700 stars and more than 1,200 forks: display modules are cheap and plentiful, but each controller family has its own command set, page addressing mode and offset quirks, and writing that per project is pure repetition. The API itself is small. You pick a constructor for your part and buffer size, then call line, box and circle primitives, or ask for a font by name and write a string. Nothing about that surface is novel. The value is in the driver table behind it, which is what the README means when it says the supported controllers include the ones listed and points to the wiki for the full list. The topic tags on the repository line up with the audience: arduino, lcd, oled, microcontroller, embedded-systems, font. Worth noting for anyone arriving from search results: the repository description still says U8glib, the name of the older generation of this library. The project name, the directory names and the README heading all say U8g2, and the description itself calls it version 2. Same lineage, current name. ## U8g2 and U8x8 split by where the frame buffer lives This is the decision the README asks you to make first, and it is a memory decision more than an API one. Both halves ship inside the same library and share the same drawing primitives. The U8g2 half includes all graphics procedures, supports many fonts with almost no restriction on font height, and needs some memory in the microcontroller to render the display. The U8x8 half is a text output device only: fonts have to fit an 8x8 pixel grid, and writes go straight to the display, so no buffer in the microcontroller is required. That distinction matters more on an AVR part with two kilobytes of RAM than it does on a board with 512. A full page buffer on a 128 by 64 monochrome panel is about a kilobyte, which is half your SRAM before you have allocated anything else. U8x8 exists precisely for that case, and it is also the reason U8x8 fonts look worse: you give up proportional sizing and any height above eight pixels. Both are selected at construction time by choosing the constructor, so switching between them later is a code change in one place rather than a rewrite. ## Installation is one click in the Arduino IDE, everything else is wiki The installation story is one sentence: install from the library manager of the Arduino IDE. There is no dependency to chase and no toolchain to configure, which is why this library shows up in beginner projects as often as in production firmware. Everything else is documented off the README. The setup guide and reference manual live in the project wiki, and the README links it directly. That is where constructor lists, per-controller notes, the font index and the wiring details are. If you are evaluating the library, the wiki is not an optional extra; it is the manual, and the README is the signpost to it. For non-Arduino targets, the repository is not a single-platform library. The tree carries a `CMakeLists.txt`, an `SConscript`, an ESP-IDF style `component.mk`, a `pkg/` directory, and a `sys/` directory of platform glue, which is how the same sources get built under Arduino, ESP-IDF and plain make-based embedded toolchains. A Gitpod configuration is also committed, so you can open the library in a browser-based environment without setting up a cross compiler first. ## What the source tree says about how the library is put together The top level is small enough to read in one pass: `csrc/` for the C implementation, `cppsrc/` for the C++ bindings that the Arduino library manager expects, `doc/` for documentation sources, `tools/` for the font and bitmap generators, `pkg/` for packaging metadata, plus `ChangeLog` and `SConscript`. The `tools/` directory is the part people underestimate. Almost every font you name in a constructor was produced there, from a font description to a byte array sized for the target display. That is why the library can offer fonts at almost any height while staying inside a megabyte or two of flash, and it is also why custom glyphs mean running a generator rather than hand-writing an array. `sys/` is where device-specific code lives, and `.gitmodules` at the root says part of the tree is pulled in as submodules. For a reader deciding whether to vendor this into a firmware project, that arrangement matters: you cannot simply copy `csrc/` and expect the whole library, and you should look at what the submodules point at before you plan a build around it. ## License metadata and the LICENSE file disagree GitHub reports no SPDX license identifier for this repository, which means the license field is unset rather than permissive. There is a `LICENSE` file in the root of the tree, so the grant text exists, but the metadata GitHub shows on the page is empty and a machine reading the API gets nothing back. Both facts are worth keeping in view. An unset license field is common in older repositories and in projects where the maintainer never filled in the form, and it is not by itself a statement that the code is unlicensed. But if you are shipping firmware, the file in the repository is what governs, so open it and read it rather than trusting the badge. For a library as widely vendored as this one, the difference between a permissive file and a copyleft one is a legal question, not a formality. This is the kind of gap worth checking in any embedded dependency, and it is a reminder that repository metadata and repository contents drift apart independently. ## Activity, issues and what the project does not promise The repository is not archived and the last push landed on 2026-09-14, so this is a living library rather than an archived one. The open issue count sits around 281, which for a project of this age and adoption is a backlog rather than a sign of abandonment, though it does mean hardware-specific reports accumulate slowly. There are no tagged releases to point at. The Arduino library manager, which the README names as the install path, pulls the default branch, so the version you get is whatever is on the tip of the tree rather than a tagged snapshot. That is convenient and it is also less reproducible than a pinned release, which matters if your firmware build needs to be repeatable a year from now. The honest summary is that u8g2 is a mature, widely vendored library whose front page is deliberately small. It tells you which controllers work, which of its two variants to pick, and where to install it from. The specifics live one click away in the wiki, and that is where you should go before writing the first constructor call. ## Conclusion u8g2 is worth reaching for when a project needs text and simple shapes on a small monochrome screen and you would rather not learn each controller's command set from a datasheet. The buffered variant buys you arbitrary fonts at the cost of RAM, the no-buffer variant trades that away for 8x8 text only, and both share one API. What the README does not settle is anything controller-specific, so the setup guide linked from it is where the real work is. Start by matching your exact controller part number in the full list, then pick the variant that fits the memory you actually have left on the microcontroller. ## FAQ ### What are U8g2 supported displays? The README lists monochrome OLED and LCD controllers including SSD1305, SSD1306, SSD1309, SH1106, ST7565, UC1608, T6963, PCD8544, KS0108, IL3820 and many more. A complete list is kept on the project wiki rather than in the README, so match your exact part number there before writing a constructor call. ### How much memory does U8g2 use? It depends on which half you pick. The buffered U8g2 API needs a frame buffer in microcontroller RAM, roughly a kilobyte for a typical 128 by 64 panel, while the U8x8 text-only API writes straight to the display and needs no buffer. On a part with two kilobytes of RAM that difference decides which one you can use. ### Should I use U8g2 or U8x8? Use U8g2 if you need arbitrary fonts, proportional text or any drawing primitive, and if you have RAM to spare for a page buffer. Use U8x8 if you are tight on memory and only need 8x8 text, since it sends characters straight to the controller with no microcontroller-side buffer. ### How do I install u8g2 outside the Arduino IDE? The repository ships CMakeLists.txt for CMake builds, an SConscript, and a component.mk for ESP-IDF, alongside the C and C++ sources. It also commits a Gitpod configuration, so the quickest route outside Arduino is to open it in that browser environment and build there first. ## Sources - [Issues](https://github.com/olikraus/u8g2/issues) - [olikraus/u8g2 on GitHub](https://github.com/olikraus/u8g2) - [README](https://github.com/olikraus/u8g2/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/olikraus-u8g2