Skip to content

🔧 LCD_CONTROLLER to select the display - #28616

Open
ellensp wants to merge 1 commit into
MarlinFirmware:bugfix-2.1.xfrom
ellensp:lcd-controller-select
Open

ellensp wants to merge 1 commit into
MarlinFirmware:bugfix-2.1.xfrom
ellensp:lcd-controller-select

Conversation

@ellensp

@ellensp ellensp commented Sep 28, 2026

Copy link
Copy Markdown
Contributor

Description

Selects the display with a single option, the way MOTHERBOARD selects the board:

#define LCD_CONTROLLER LCD_REPRAP_DISCOUNT_SMART_CONTROLLER

Configuration.h currently lists about 100 display options, each to be uncommented on its own. They move to a new Marlin/src/core/displays.h, which works like boards.h: one numbered LCD_* value per display, each keeping the description it had in Configuration.h. Configuration.h keeps only the selector and the settings that belong to particular displays.

Configuration.h ships //#define LCD_CONTROLLER LCD_NONE; left undefined, it defaults to LCD_NONE.

How it works

  • displays.h is included beside boards.h, ahead of Configuration.h.
  • At the top of Conditionals-2-LCD.h, the selected value is mapped back to the existing option name (LCD_VIKI2 → #define VIKI2). Nothing downstream changes. An unknown value is an #error.
  • The set of displays is exactly the existing "Please select only one LCD controller option" count, so every selectable display is one Marlin already treats as mutually exclusive.
  • DGUS has one value per UI (LCD_DGUS_ORIGIN … LCD_DGUS_E3S1PRO), which set DGUS_LCD_UI.

Display settings in Configuration.h

Configuration.h is read before the selection is mapped, so a block like #if ENABLED(TFT_GENERIC) in it would be skipped for a display chosen with LCD_CONTROLLER. displays.h adds LCD_IS(NAME), true when NAME is either enabled by name or selected, and these blocks now use it:

MIGHTYBOARD_LCD, DGUS (MKS, IA_CREALITY), ANYCUBIC_LCD_I3MEGA, EXTENSIBLE_UI, TFT_GENERIC, DWIN_CREALITY_LCD.

Options chosen alongside a display stay separate: TFT_CLASSIC_UI / TFT_COLOR_UI / TFT_LVGL_UI, TFT_ROTATION, TOUCH_SCREEN, REPRAPWORLD_KEYPAD, EASYTHREED_UI.

SAV_3DGLCD

SAV_3DGLCD needed a second option for its OLED controller. It becomes two displays, SAV_3DGLCD_SSD1306 and SAV_3DGLCD_SH1106 (LCD_SAV_3DGLCD_SSD1306 / LCD_SAV_3DGLCD_SH1106), which set SAV_3DGLCD and the matching U8GLIB_* driver. Its options block is removed from Configuration.h, and the sanity check for a missing or doubled driver now names the two new values.

Compatibility

Existing configurations are unaffected:

  • Enabling a display by name (#define VIKI2) and setting DGUS_LCD_UI still work.
  • SAV_3DGLCD with U8GLIB_SSD1306 or U8GLIB_SH1106 still works.
  • Selecting two different displays, either way, hits the existing "only one LCD controller" error.

Tooling

  • opt_enable <display> / opt_disable <display>: the names are no longer in Configuration.h, so a display name now sets or clears LCD_CONTROLLER. Other unknown names are still errors.
  • opt_set DGUS_LCD_UI ... and test .ini files that name a display keep working, since both add options that aren't present.
  • schema.py offers the LCD_* values as choices for LCD_CONTROLLER, as it does for MOTHERBOARD.

Fix

EMOTION_TECH_LCD was missing from the "only one LCD controller" count, so it could be combined with another display without an error. It's now counted and selectable.

Requirements

None.

Benefits

A display is chosen by setting one option to a name from a list, instead of finding and uncommenting the right line among about 100. Display-specific settings sit together in Configuration.h.

Configurations

The example configurations enable displays by name and keep building, but their LCD sections no longer match the new default layout. Before the next import, import-2.1.x needs its examples converted to LCD_CONTROLLER. The tooling that propagates default-config changes into the examples and builds the bugfix / release branches also needs to handle the new LCD section. The documentation for choosing a display (currently "uncomment the line for your display") needs updating to match.

Testing

  • Default configuration (mega2560): identical binary to bugfix-2.1.x apart from the embedded build time.
  • The same display chosen by name on bugfix-2.1.x, by name on this branch, and with LCD_CONTROLLER: identical binaries apart from the build time. Tested for RRD Full Graphic, SAV_3DGLCD SSD1306 and SH1106, TFT_GENERIC (LERDGE-K, FSMC, Color UI) and DGUS MKS.
  • An unknown LCD_CONTROLLER value, and two different displays, each fail with a clear error.
  • CI targets mega2560, STM32F103RE_creality, mks_robin_pro2, LERDGEK and mega2560ext (29 configurations) pass, including a new mega2560/config-11.ini that selects LCD_SAV_3DGLCD_SH1106.

Related Issues

None.

@thinkyhead

Copy link
Copy Markdown
Member

I've always wanted to do something along these lines, or at least separate LCD configuration options into a third configuration file. But then we may as well start breaking up configurations into dozens of files based on feature. The main caveat with this change is that it removes documentation for displays from Configuration.h and creates the requirement for users to look outside of the configuration file to look up the identifier for their LCD controller.

One might say, well we already have to look outside to find the correct name for the MOTHERBOARD. And that would be fair to point out.

To support this change HAS_LCD needs to be implemented in Auto Build Marlin, scraping from core/displays.h. And committing to this change means providing a script to update all example configurations to the new scheme. This also impacts the readiness of ongoing migration work being done in both Auto Build Marlin and here.

Since this change is so impactful to configurations it probably ought to be deferred until after the upcoming release.

@ellensp
ellensp force-pushed the lcd-controller-select branch from 6e9a213 to a2d5667 Compare October 24, 2026 13:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants