Apply the theme, calculate dimensions, highlight the menu and arrange
the scene correctly, so that everything is ready to go when the expo
is rendered.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some callers may wish to add items later as they are discovered. Split
the setup code into its own function, to permit this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than returning a bootflow, return the index of the bootflow. This
will allow callers to do their own translation to bootflows or some
other data structure.
Also return a special code when the user tries to move the pointer, so
that the caller can cancel the boot-menu timeout, if this is in use.
Signed-off-by: Simon Glass <sjg@chromium.org>
The menu is currently quite basic. Make use of some recently added
features in expo, to:
- Show proper prompts
- Highlight the current item
- Centre text
- Use multi-line text instead of two independent lines
- Put a box around the items
Signed-off-by: Simon Glass <sjg@chromium.org>
It is often necessary to centre objects within the display area. Add a
special position value to indicate this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Within tests it is useful to be able to control rendering of the expo.
Drop the automatic call to expo_render() within expo_poll() and adjust
its callers to handle this instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
If the user does not quickly provide some input, exit so that other
things can be done, such as searching for the next OS.
Signed-off-by: Simon Glass <sjg@chromium.org>
Expo normally uses a pointer to show the current item. Add support for
highlighting as well, since this makes it easier for the user to see the
current item.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide some forward declarations for types used in this file, to keep
the LSP happy and avoid errors if the caller happens not to include the
required header.
Signed-off-by: Simon Glass <sjg@chromium.org>
The gap is intended to separate options which are on different bootdevs,
but most of the time there is only one. So drop this gap.
Keep the code around in case it becomes useful to have it in the style,
or based on some other mechanism.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to edit text, e.g. to allow the user to edit the
environment or the command-line arguments for the OS.
Add the beginnings of an implementation. Future work is needed to finish
this: keypress handling and scrolling. For now it just displays the
text.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for left, right and centred alignment for text, in the
horizontal dimension.
Also support top, bottom and centred in the vertical dimension, for the
text object as a whole.
Alignment is not yet implemented for images. It has no meaning for
menus. A textline object uses a text object internally, so alignment
is supported there.
Provide some documentation to explain how objects are positioned.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to draw a box around elements in the menu. Add
support for an unfilled box with a selectable thickness.
Note that there is no support for selecting the colour for any expo
objects yet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the measurement info to write each line of text separately, thus
respecting word-wrapping and newlines.
Fix up the comment for scene_obj_render() while we are here.
Since a lineedit does not support alignment, add a special case to just
display the text if there is no measurement. This happens assuming the
lineedit is initially empty.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases dynamic text is needed, e.g. for a menu countdown. Add a
function which handles this, allowing the caller to take control of the
text that is shown on each render.
Signed-off-by: Simon Glass <sjg@chromium.org>
In preparation for adding more text types, refactor the common fields
into a new structure. This will allow common code to be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a function to allow the size of an object to be set independently
of its position.
Also add a function to permit the object's bounding box to be set
independently of its dimensions.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases it is useful to obtain more than just two bounding boxes
from a menu, e.g. to line up all descriptions vertically.
Use an array to obtain bounding-box information and calculate it
separately for each item.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present each object has a width and height and the bounding box is
implicit in that.
This is not flexible enough to handle objects which are larger than
their contents might need. For example, when centring a text object we
might want to have it stretch across the whole width of the display even
if the text itself does not need that much space.
Create a new 'dimensions' field and convert the existing width/height
into x1/y1 coordinates.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is more convenient to put strings in an abuf so they can easily be
resized. Adjust the struct accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
These coordinates are the top left values, so rename them to x0 and y0
in preparation for changing the width and height to x1 and y1
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we assume that each object is a simple box and that it fills
the whole box.
This is quite limiting for text objects, which we may want to centre
within the box. We need a position within the box where drawing starts.
Rename the scene_dim struct to indicate that it is a bounding box.
Signed-off-by: Simon Glass <sjg@chromium.org>
Refactor bootflow_menu_add_all() to call a new bootflow_menu_add() to
add each of its bootflows.
Move the last_bootdev value into struct menu_priv to make this work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Split the iteration piece of this function into bootflow_menu_add_all()
so that it is possible for the caller to be in control of adding items
to the menu.
Move the expo_destroy() call into the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Split the starting piece of this function into bootflow_menu_start()
and the polling part into bootflow_menu_poll() so that it is possible
for the caller to be in control of the event loop.
Move the expo_destroy() call into the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present when the user moves to a new menu item, the menu code
handles this immediately. This means it is not possible to use an expo
action to effect the same change.
Update this so that EXPOACT_POINT_ITEM is handled in cedit_do_action().
Expand the test to cover this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add functions to allow a caller to find out the current menu item and to
select a different one.
Update the event handling so that an attempt to change the current item
(e.g. by pressing the up-arrow key) is reported to the caller, since
this may be used to cancel an autoboot timeout.
Signed-off-by: Simon Glass <sjg@chromium.org>
Refactor the action-processing code into a new cedit_do_action()
function so we can call it from a test. Check moving to a new field and
opening the menu, to ensure that rendering is correct.
Signed-off-by: Simon Glass <sjg@chromium.org>
Both bootflow_menu and cedit use similar logic to poll an expo. Move
this into the expo library so the code can be shared.
Update bootflow_menu_run() to return -EPIPE when the user quits without
choosing anything, since -EAGAIN is ambiguous and elsewhere means that
there is no input yet.
Signed-off-by: Simon Glass <sjg@chromium.org>
An expo generally needs to keep track of the keyboard state while it is
running, so move the context into struct expo
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct appears in various places. Reduce code size by adding a
function for it.
It inits the abuf, then allocates it to the requested size.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tom Rini <trini@konsulko.com> says:
Hey all,
This is a v3 of Simon's series[1] and depends on the series[2] I posted
the other day that removes <env.h> from <command.h>. With this series
done, I believe we've tackled all of the current cases of headers which
include <env.h> without directly needing it. Much of this series is in
fact Simon's v2 with the main differneces being:
- Removing <env.h> from <net.h> at the end
- Removing env_to_ip() given how little it's used rather than shuffling
around where it's declared and un-inline'ing it. For a rarely used
helper, this ends up being cleaner I think. Especially looking at some
of the users (which called env_get repeatedly). If there's strong
opinion here about using the other method[3] we can do that instead.
- Setting aside for now how to handle CMD_ELF=y and NO_NET=y because
today it's actually fine as we unconditionally build lib/net_utils.c
where string_to_ip() is defined. I'm unsure if a further series is
warranted here or not. We rely on link-time optimization to keep code
readable too.
[1]: https://lore.kernel.org/all/20250501010456.3930701-1-sjg@chromium.org
[2]: https://lore.kernel.org/all/20250514225002.15361-1-trini@konsulko.com
[3]: https://lore.kernel.org/all/20250501010456.3930701-23-sjg@chromium.org
Link: https://lore.kernel.org/r/20250515234154.1859366-1-trini@konsulko.com
Now that env_get_ip() has been removed, the include file <net.h> does
not need anything from <env.h>. Furthermore, include/env.h itself
includes other headers which can lead to longer indirect inclusion
paths. To prepare to remove <env.h> from <net.h> fix all of the
remaining places which had relied on this indirect inclusion to instead
include <env.h> directly.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # net/lwip
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The include file <command.h> does not need anything from <env.h>.
Furthermore, include/env.h itself includes other headers which can lead
to longer indirect inclusion paths. To prepare to remove <env.h> from
<command.h> fix all of the places which had relied on this indirect
inclusion to instead include <env.h> directly.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> # android, bcb
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # spawn
Signed-off-by: Tom Rini <trini@konsulko.com>
In a number of cases we have C files which rely on a chain of indirect
include paths to get <linux/string.h> to be included via <command.h>. To
facilitate cleaning up <command.h> make this code directly include
<linux/string.h>.
Signed-off-by: Tom Rini <trini@konsulko.com>
Similar to ARM and X86, introduce a new image type which allows u-boot
to distinguish between images built for 32-bit vs 64-bit Risc-V CPUs.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Maxim Moskalets <maximmosk4@gmail.com>
The bootstd code itself does not have any dependency on BLK in order to
build. However, in order to minimize size growth of non-migrated
platforms, change this from being "default y" to "default y if BLK".
This will make it easier to begin migration of platforms which do not
have any BLK-class device but do want to use bootstd.
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently, when decompressing a gzip-compressed image during bootm, a
generic error such as "inflate() returned -5" is shown when the buffer is
too small. However, it is not immediately clear that this is caused by
CONFIG_SYS_BOOTM_LEN being too small.
This patch improves error handling by:
- Detecting Z_BUF_ERROR (-5) returned from the inflate() call
- Suggesting the user to increase CONFIG_SYS_BOOTM_LEN when applicable
- Preserving the original return code from zunzip() instead of overwriting
it with -1
By providing clearer hints when decompression fails due to insufficient
buffer size, this change helps users diagnose and fix boot failures more
easily.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Expo needs to be able to word-wrap lines so that they are displayed as
the user expects. Add a limit on the width of each line and support this
in the measurement algorithm.
Add a log category to truetype while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the vidconsole API so that measure() can measure multiple lines
of text. This will make it easier to implement multi-line fields in
expo.
Tidy up the function comments while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
