Thanks for your feedback, Laszlo. I like the idea to support hotkey from VFR level. However, I checked the UEFI driver writer guide and I do not see anything about HII hotkey.
In terms of hotkey support from VFR, the efforts may be bigger than doing it from EDK2 protocol. VFR file is compiled into IFR Opcodes and IFR Opcodes are defined in UEFI specification. That means we have to update UEFI specification to support HII hotkey. This also includes the changes to VFR compiler, EDK2 setup browser driver and all other codes that will parse IFR opcodes. I am not sure if it is worth doing this.
Thanks,
Nickle
toggle quoted message
Show quoted text
-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Wednesday, March 24, 2021 7:37 PM
To: rfc@edk2.groups.io; Wang, Nickle (HPS SW) <nickle.wang@...>
Cc: Dandan Bi <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Subject: Re: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support
On 03/24/21 09:21, Nickle Wang wrote:
Hi All,
I am having trouble to disable hotkey support in HII browser with existing
interface. I am wondering if we could have new interface to disable hotkey
support in form browser extension2 protocol.
1. Background:
In some HII driver, there is no need to have hotkey support in certain HII
menu due to its design. The examples are EDK2 iSCSI driver, secure boot
configuration and Tls auth configuration driver. In these HII menus, there is
HII button to do submit or discard job and they do not answer to hotkey
action. I also see this design in 3rd party option card driver. In this case, user
feels confused because it dose not do anything while pressing hotkey. The
only way to save or discard data is by pressing the button on HII menu. So,
we need to disable hotkey support and force user to use HII button.
I agree with the problem statement. I've noticed this too, and found it
confusing.
I wonder if there are HII guidelines or best known practices to deal with it -- I
assume that one desirable solution might be if we could control the hotkeys
just from the VFR, one way or another. But indeed I don't know if that's
feasible by design.
Thanks
Laszlo
2. Issue:
Currently we have
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.RegisterHotKey to create
or delete hotkey support. With value 0 in "Action", we can delete
corresponding hotkey.
typedef
EFI_STATUS
(EFIAPI *REGISTER_HOT_KEY) (
IN EFI_INPUT_KEY *KeyData,
IN UINT32 Action,
IN UINT16 DefaultId,
IN EFI_STRING HelpString OPTIONAL
);
However, there are some troubles for driver or option card driver to use it
and delete hotkey support.
* Usually, display engine is the one who creates hotkey in HII browser. So
driver has no information about the key data. And there is no way to get
these hotkey information programmatically.
* If driver tries to delete hotkey for its HII menu, it requires driver to
restore hokey support when user leaves its HII menu. This could easily break
the hotkey support in HII browser because display engine has no control to
this.
3. Proposal:
I would like to propose new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL so that driver can
temporarily disable hotkey support for certain HII menu in its own form-set.
And display engine will handle the hotkey support accordingly.
struct EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL {
...
REGISTER_HOT_KEY RegisterHotKey;
DISABLE_HOT_KEY DisableHotKey;
...
};
/**
Disable the hotkey by given its browser action.
@param[in] Action Action value to disable corresponding hotkey.
@param[in] Scope Hotkey scope level to be disabled.
@retval EFI_SUCCESS Hotkey is disabled.
@retval EFI_NOT_FOUND Hotkey with given Action is not found.
**/
typedef
EFI_STATUS
(EFIAPI *DISABLE_HOT_KEY) (
IN UINT32 Action,
IN BROWSER_SETTING_SCOPE Scope
);
May I have your comment about this? Is this good idea for driver to disable
hotkey support?
Thanks,
Nickle
