UEFI HII (Part 2)

This week, we will look at some of the key elements of the Human Interface Infrastructure portion of the UEFI 2.1 and later specifications. UEFI platform firmware provides two key facilities:

1. The HII Database. The database acts a repository for all sorts of configuration and user-interface resources, including forms, fonts, strings, images, animations, and keyboard layouts. The platform and individual drivers can install and remove these resources.
2. The HII Forms Browser. The browser is the platform-provided user interface where the forms are displayed and input from the user is taken in order to update configuration settings.

The platform firmware decides when the user interface should be displayed. This is different from legacy BIOS and UEFI 2.0, where individual option ROMs could put up their own user interface elements, provide their own boot hot keys for entering those utilities and delay the boot in order to display instructions and copyright information. Now, with UEFI 2.1 and beyond, the individual drivers provide user interface information to the platform and the platform presents it to the user.

In most implementations, the decision about when is controlled by the UEFI Boot Manager. The how might be part of the boot manager itself or a separate driver or application. Why? The boot manager is already responsible for hot keys for launching boot options and applications. The boot manager is also responsible for the UEFI driver health support and the UEFI user identification support, both of which can be user-interface intensive and are heavily involved with the boot process.

For drivers, the most important API is the EFI_HII_DATABASE_PROTOCOL. Normally, during driver initialization (if one page manages all driver-supported devices) or during Start(), the driver will install the forms and strings that it will use for configuration, driver health and user identification using NewPackageList().

The next important API for drivers is the EFI_HII_CONFIG_ACCESS_PROTOCOL, which is provided by the driver to handle configuration-related behaviors. This protocol provides three important functions:

1. ExtractConfig(). Return the current configuration settings.
2. RouteConfig() . Change the current configuration settings.
3. Callback(). Handle callbacks while the user is interacting with the forms.

That's it. The driver publishes forms and strings and provides a way to read and write configuration values and handle callbacks from the forms. Of course, there's a lot more in the nitty-gritty details and we'll dig into that soon.

But next, week we will spend a little time on how the resources are put together and delivered to the HII Database and even OS-present applications.