U-Boot’s expo subsystem provides a way to create graphical menus and forms for user interaction. One key component is the textline object, which allows users to enter text, for example when typing a password or a filename.
This post describes recent work to support multiple vidconsole contexts, making it easier for expo to handle multiple independent text-input fields on the same display.
The Problem
The original textline implementation was designed around U-Boot’s command-line editor. When a textline is ‘opened’, the text is written out using vidconsole and the state is saved. When the user types a character, the state is restored, the character is written, and the state is saved again.
This approach has several limitations. Cursor movement is inefficient: when the user presses Ctrl-A to move to the start of the line, backspaces are written to reposition the cursor. Inserting a character then requires rewriting the entire string.
More fundamentally, all text operations share the same vidconsole context, making it impossible to have multiple, truly-independent text fields on the screen at once. Characters typed into a textline also appear on the text console, which is undesirable in a graphical interface.
Looking ahead, the approach cannot easily extend to a textedit widget that needs to handle multiple lines of text with up/down navigation. The tight coupling between expo and the CLI editor becomes a significant limitation.
The Solution
The solution involves threading a vidconsole context pointer through the entire video console stack. This enables each text-input object to maintain its own cursor position, font settings, CLI line state, and cursor appearance.
The changes span several layers. At the foundation, the vidconsole uclass now maintains a list of contexts and provides functions to allocate and free them. Each context contains cursor position, font metrics, and CLI state.
All vidconsole functions now accept an optional context parameter. When NULL is passed, the default context used by the command line is selected. This maintains backward compatibility while enabling the new functionality.
At the expo level, each textline object can now have its own vidconsole context, allocated when the object is created and freed when destroyed. The CLI line state, which tracks the text buffer and cursor position within the text, moves from the scene into each text-input object.
Implementation
The series begins by adding a context parameter to low-level functions like vidconsole_put_char() and vidconsole_set_cursor_pos(). This change propagates upward through vidconsole_put_string(), the escape sequence handler, and eventually to the expo rendering code.
With the plumbing in place, the CLI line state moves from being shared at the scene level to being owned by each text-input object. This means each textline tracks its own text buffer, cursor index, and editing state independently.
The vidconsole uclass gains an alist of contexts, managed through vidconsole_ctx_new() and vidconsole_ctx_dispose(). When expo creates a text-input object, it can request a dedicated context that will be used for all rendering operations on that field.
Finally, context allocation centralises in the uclass rather than being scattered across individual drivers. This reduces code duplication and ensures consistent setup of cursor buffers, font metrics, and initial state.
Benefits
This refactoring enables forms with multiple independent text-input fields, each maintaining its own cursor and editing state. A login form could have separate username and password fields, each responding to input independently.
The clean separation between text-input objects and the global command-line state means that typing in an expo field no longer echoes characters to the text console. The user interface becomes self-contained.
Perhaps most importantly, this architecture provides the foundation for multi-line text editing widgets. A textedit control that supports scrolling through many lines of text, with up and down arrow navigation, becomes feasible once each widget owns its own context.
The size impact is modest: approximately 300 bytes on Thumb2 for boards that enable both command-line editing and expo. This is a reasonable cost for the added functionality and cleaner architecture.
Conclusion
Adding multiple vidconsole context support to U-Boot’s expo subsystem enables more sophisticated user interfaces with multiple independent text-input fields. While the implementation required threading a context pointer through many functions, the result is a cleaner architecture that supports future enhancements like multi-line editing and independent cursor blinking per field.
The changes maintain full backward compatibility. Existing code that passes NULL for the context continues to work exactly as before, using the default context shared with the command line.
