[PATCH 00/24] bootstd: Add a boot menu

[Simon Glass]

Hi Heinrich,

On Mon, 17 Oct 2022 at 15:23, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Heinrich,
>
> On Mon, 17 Oct 2022 at 15:11, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >
> > On 10/17/22 22:29, Simon Glass wrote:
> > > So far standard boot lacks a boot menu, although it is possible to create
> > > a rudimentary one using the existing 'bootmenu' command.
> > >
> > > Even then, this text-based menu offer only basic functionality and does
> > > not take full advantage of the displays which are common on many devices.
> > >
> > > This series provides a 'bootflow menu' command which allows the user to
> > > select from the available bootflows. An attempt is made to show the name
> > > of the available operating systems, by reading more information into the
> > > bootflow. A logo can be read also, where supported, so that this can be
> > > presented to the user when an option is highlighted.
> > >
> > > Full use is made of TrueType fonts, if enabled. For cases where only a
> > > serial console is available, it falls back to a simple text-based menu.
> > >
> > > All of this is implementing using a new 'expo' construct, a collection of
> > > scenes (like menu screens) which can be navigated by the user to view
> > > information and select option. This is fairly general and should be able
> > > to cope with a wider array of use cases, with less hacking of the menu
> > > code, such as is currently needed for CMD_BOOTEFI_BOOTMGR.
> > >
> > > Of course it would be possible to enhance the existing menu rather than
> > > creating a new setup. Instead it seems better to make the existing menu
> > > use expo, if code space permits. It avoids the event-loop problem and
> > > should be more extensible, given its loosely coupled components and use of
> > > IDs instead of pointers. Further motivation is provided in the
> > > documentation.
> > >
> > > For now the CLI keypress-decoding code is split out to be used by the new
> > > menu. The key codes defined by menu.h are reused also.
> > >
> > > This is of course just a starting point. Some ideas for future work are
> > > included in the documentation.
> >
> > Hello Simon,
> >
> > Linaro's implementation of a boot menu for UEFI booting showed that the
> > current basis of bootmenu is inadequate for properly designing a GUI
> > like user interface.
> >
> > With your patch set you try to overcome this. Your design document in
> > patch 24 identifies a hierarchy of objects expo - scene - design element
> > but otherwise remains rather sketchy to me.
>
> For now the doc is here:
>
> https://docs.google.com/document/d/1VQeApnLlH6xKm_OI36AhWkJLUEd9OXEvIJXB8aM2de8/edit?usp=sharing&resourcekey=0-DwgHpR2S8vJEJzvvwPb-AQ
>
> >
> > Before investing into code we should a more holistic design perspective.
> >
> > First thing we need to define is our requirements, e.g.
> >
> > ** Which input devices do we want to support in future **
> >
> > - keyboard
> > - mouse
>
> I have patches for mouse, actually.
>
> >
> > ** What type of GUI do we want to support **
> >
> > - text terminal
> > - graphical output
> >
> > ** Which design elements do we need **
> >
> > - lists
> > - trees
> > - grids
> > - menus
> > - labels
> > - buttons
> > - drop down lists
> > - combo boxes
> > - bitmaps
> > - screens (you call them scene)
> > - transactions (you call them expo)
>
> (this series has rudimentary menus, labels and bitmaps, but does not
> support the others)
>
> >
> > ** How do we want to structure our GUI **
> >
> > - Good practice is to clearly separate model, view, and controller.
>
> Expo is the view. Controller is the client code. Model is currently
> the expo, updated by the controller. That part of it needs though if
> we are to expand the capabilities of this effort.
>
> >
> > ** Which constraints do we have to observe? **
> >
> > - How much is the code base allowed to grow?
> > - Who will be the long term sponsor and maintainer?
> >
> > After having this rough cut overview we may start with a draft
> > implementation and detail our design document.
> >
> > How do you plan to organize the design work?
>
> See also the bottom of the docs for some future work, also whether we
> should consider using a GUI library like Nuklear in the future:
>
> https://patchwork.ozlabs.org/project/uboot/patch/20221017203000.2207887-25-sjg@chromium.org/
>
> It has evolved since that doc. The doc needs to evolve further.
> Perhaps we can start by agreeing the requirements.

I have updated the doc to accommodate some of your comments and to
indicate exactly how unicode and languages might be supported.

https://docs.google.com/document/d/1VQeApnLlH6xKm_OI36AhWkJLUEd9OXEvIJXB8aM2de8/edit?resourcekey=0-DwgHpR2S8vJEJzvvwPb-AQ#

Please add any comments to the doc, or put them in this thread.

I'll rework the patches a little and send out a new version.

Regards,
Simon