Hi Dandan,

Thank you for your feedback. Yes I think we need an interface between HII modules and Browser in UEFI specification.

I think we may mention the optional hot key service for browser implementation in UEFI spec and describe the purpose and use case clearly in Spec

Sounds a good idea. Thanks.

Nickle

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Dandan Bi
Sent: Wednesday, April 28, 2021 10:29 AM
To: Wang, Nickle (HPS SW) <nickle.wang@...>; gaoliming <gaoliming@...>; rfc@edk2.groups.io; lersek@...
Cc: 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

Hi Nickle,

I also think Liming's suggest is good that add EFI_BROWSER_ACTION_REQUEST_XXX in UEFI spec to enable the communication between HII modules and Browser for the hot key status.
And each Browser can enable/disable hot key as its own way if it has the capability.
I think we may mention the optional hot key service for browser implementation in UEFI spec and describe the purpose and use case clearly in Spec if we add the new EFI_BROWSER_ACTION_REQUEST_XXX In UEFI spec for hot key related.



Thanks,
Dandan

-----Original Message-----
From: Wang, Nickle (HPS SW) <nickle.wang@...>
Sent: Tuesday, April 27, 2021 11:59 AM
To: gaoliming <gaoliming@...>; rfc@edk2.groups.io;
lersek@...; Bi, Dandan <dandan.bi@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Wang,
Nickle (HPS SW) <nickle.wang@...>
Subject: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Hi Liming,

Thank you very much for your feedback. I agree with your idea and it
would be good to address this issue from UEFI interface instead of EDK2 interface.
However, since there is nothing about HII hotkey in UEFI specification now.
This will bring HII hotkey as standard HII interface in UEFI
specification. I am expecting more efforts than doing this in EDK2 interface.

Hi Dandan,

May I have your comments about this? We had talked about this before
and we think HII hotkey is only EDK2 browser implementation. If we
want to have HII hotkey defined in UEFI specification, do you see any objection to this?

For now, I suggest OptionRom driver adds some information in its
help

message to display them in Setup page. It can notify the user that it
doesn't support HotKey. For long term, I propose to introduce new
EFI_BROWSER_ACTION type in UEFI spec for the communication between
Browser and HII module. When HII module page open, it can return its
status of system hot key to Browser, then browser can control whether
enable hotkey.

This is good suggestion, Thanks! And the idea of new
EFI_BROWSER_ACTION looks good to me too. I will check and see how to do this.

Thanks,
Nickle

-----Original Message-----
From: gaoliming <gaoliming@...>
Sent: Tuesday, April 27, 2021 11:32 AM
To: Wang, Nickle (HPS SW) <nickle.wang@...>; rfc@edk2.groups.io;
lersek@...
Cc: 'Dandan Bi' <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey support

Nickle:
Sorry for the late response. In fact, there is no UEFI interface
between system browser and single HII module.
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL is edk2 implementation.
This is not UEFI interface. OptionRom card needs to follow UEFI, and
work on UEFI system. So, I don't suggest that HII module consumes
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL. For now, I suggest OptionRom
driver adds some information in its help message to display them in
Setup page. It can notify the user that it doesn't support HotKey. For
long term, I propose to introduce new EFI_BROWSER_ACTION type in UEFI
spec for the communication between Browser and HII module. When HII
module page open, it can return its status of system hot key to
Browser, then browser can control whether enable hotkey.

Thanks
Liming

-----邮件原件-----
发件人: Wang, Nickle (HPS SW) <nickle.wang@...>
发送时间: 2021年4月26日 11:15
收件人: rfc@edk2.groups.io; Wang, Nickle (HPS SW)

<nickle.wang@...>;

gaoliming@...; lersek@...
抄送: 'Dandan Bi' <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>; Wang, Nickle (HPS SW)
<nickle.wang@...>
主题: RE: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey

support

Hello Liming,

Just a friendly reminder in case you miss this email. It seems to me
that if we do not create the interface to disable HII hotkey, we
still need some improvement to HII in order to address the issues
that I mentioned. What do you think about this?

Thanks,
Nickle

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Nickle
Wang
Sent: Friday, April 16, 2021 4:13 PM
To: rfc@edk2.groups.io; gaoliming@...; lersek@...
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

Hi Liming,



Thanks for your comments. I got a chance to talk to option card
vendor and they share two cases that HII driver is not able to support hotkey.



1) Driver cannot support hotkey to load defaults.



Form EDK2 display engine driver
(MdeModulePkg\Universal\DisplayEngineDxe), it binds load default
hotkey to standard default.



[cid:image001.png@...]



However, there is no interface for option card driver to see what
default type that hotkey support. When option card driver supports
OEM defaults or the defaults other than display engine sets, nothing
will happen. And different IBV may support different default setting
with hotkey. So option card driver has to implement their own HII
button to

address this interoperability Issue.

2) Driver needs user to submit data before user leaves certain HII menu.
Hotkey does not work in this way.



This is the example from EDK2 iSCSI driver again. Below are the
steps to add iSCSI Attempt:



[cid:image003.png@...]



Due to the design of iSCSI HII driver, user has to submit data at
step
3 before user goes back to step 2 and select another network
interface. If user does not submit data at step 3, all user’s input
may be lost after user selects another network interface. However,
we have no way to force user to press
F10 hotkey here. By EDK2 design, hotkey works in form-set scope.
User can press hotkey at anywhere when user finish the
configuration. As the result, option card driver has to disable
hotkey and force user to use HII button to submit data.



So, what do you think about above two cases?



Thanks,

Nickle



-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of gaoliming
Sent: Tuesday, March 30, 2021 9:16 AM
To: rfc@edk2.groups.io; Wang, Nickle (HPS SW) <nickle.wang@...>;
lersek@...
Cc: 'Dandan Bi' <dandan.bi@...>; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Subject: 回复: [edk2-rfc] [RFC] Have new interface in
EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey

support

Nickle:

-----邮件原件-----

发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>

<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Nickle Wang

发送时间: 2021年3月26日 12:05

收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;

gaoliming@...<mailto:gaoliming@...>;
lersek@...<mailto:lersek@...>

抄送: 'Dandan Bi' <dandan.bi@...<mailto:dandan.bi@...>>;

Chang, Abner (HPS SW/FW

Technologist) <abner.chang@...<mailto:abner.chang@...>>;

Wang, Nickle (HPS SW)

<nickle.wang@...<mailto:nickle.wang@...>>

主题: Re: [edk2-rfc] [RFC] Have new interface in

EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey

support

Thanks for your feedback, Liming. Please see my comment below.

-----Original Message-----

From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>

<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of
gaoliming

Sent: Friday, March 26, 2021 9:51 AM

To: Wang, Nickle (HPS SW)

<nickle.wang@...<mailto:nickle.wang@...>>;
rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;

lersek@...<mailto:lersek@...>

Cc: 'Dandan Bi'
<dandan.bi@...<mailto:dandan.bi@...>>;

Chang, Abner (HPS SW/FW

Technologist) <abner.chang@...<mailto:abner.chang@...>>

Subject: 回复: [edk2-rfc] [RFC] Have new interface in

EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey

support

Nickle:

-----邮件原件-----

发件人: Wang, Nickle (HPS SW)

<nickle.wang@...<mailto:nickle.wang@...>>

发送时间: 2021年3月25日 15:41

收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;

gaoliming@...<mailto:gaoliming@...>;

lersek@...<mailto:lersek@...>

抄送: 'Dandan Bi'

<dandan.bi@...<mailto:dandan.bi@...>>; Chang, Abner (HPS
SW/FW

Technologist)

<abner.chang@...<mailto:abner.chang@...>>;

Wang, Nickle (HPS SW)

<nickle.wang@...<mailto:nickle.wang@...>>

主题: RE: [edk2-rfc] [RFC] Have new interface in

EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey

support

-----Original Message-----

From: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>

<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> On Behalf Of

gaoliming

Sent: Thursday, March 25, 2021 11:40 AM

To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;

lersek@...<mailto:lersek@...>; Wang, Nickle (HPS SW)

<nickle.wang@...<mailto:nickle.wang@...>>

Cc: 'Dandan Bi'

<dandan.bi@...<mailto:dandan.bi@...>>; Chang, Abner (HPS
SW/FW

Technologist)

<abner.chang@...<mailto:abner.chang@...>>

Subject: 回复: [edk2-rfc] [RFC] Have new interface in

EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL to disable hotkey

support

-----邮件原件-----

发件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>

<rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>> 代表 Laszlo

Ersek

发送时间: 2021年3月24日 19:37

收件人: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>;

nickle.wang@...<mailto:nickle.wang@...>

抄送: Dandan Bi

<dandan.bi@...<mailto:dandan.bi@...>>; Chang, Abner (HPS
SW/FW

Technologist)

<abner.chang@...<mailto:abner.chang@...>>

主题: 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.

UEFI driver write guide 12.6.1 Minimize callbacks section

defines the guide line.

https://github.com/tianocore/tianocore.github.io/wiki/UEFI-D
ri
ve

r-

Writer%27s-Guide

But, some HII drivers still like to control
submit/discard/exit

in its form by Callback function.

Hotkey way is to consume HII driver ConfigAccess protocol

RouteConfig() function for data saving.

So, HotKey doesn't work on those drivers.

For this proposal, I want to understand when new interface
will

be trigged and what module calls this new API.

The module to call this new API is the HII driver which has no

hotkey support in its HII menu. The HII driver could also be
option card

driver.

As for when the new interface will be triggered, there are two

cases in my

mind:

1. Driver wants to disable hotkey support for entire HII form-set.

1.1 Driver will call new interface in ExtractConfig()
function

with Scope "FormSetLevel".

1.2 Driver calls new interface in Callback() function when

Action is set to EFI_BROWSER_ACTION_FORM_OPEN. With Scope "

FormLevel",

this

will disable hotkey for every HII menu.

2. Driver only disable hotkey support for certain HII menu.

2. Same as 1.2 but driver have condition check to see if
this is

target HII menu or not. The Scope is set to " FormLevel" and
the

hotkey support is restored automatically by display engine
when

user

leaves this HII menu.

So, your proposal is to let HII driver call new API to disable
or

enable Hotkey on its page.

There are still some issues here.

1. UEFI option rom driver is the independent driver. It refers
to

the standard UEFI interface.

But, form browser extension2 protocol is edk2 extension. Other
UEFI

implementation may not provide this protocol.

It would be good if we could have HII hotkey definition in UEFI

specification.

But it looks like the HII hotkey support is just EDK2 form browser

implementation specific. So I would like to address the issue from

EDK2 protocol.

As far as I know, option card vendor has chance to support edk2

protocol because edk2 is kind like the industrial UEFI implementation.

And it is also easy to know if this system supports form browser
extension2

protocol or not.

Option card driver could code its behaviour accordingly

Browser implementation may be different. Please see the message

INVALID URI REMOVED

11__;!!NpxR!wupnCRk9oRVDzLRnKKZ37ZViIaEVk29Pp5op9BRoPlUqTws1e2Zf
FHMl8x

V5F-0$

2. Browser may have the different Hotkey. UEFI driver doesn't
know

to disable which Hotkey.

Yes, I also noticed this. So the new interface accept "Action" of

hotkey as parameter. So that UEFI driver does not need to know
which

hotkey he has to disable. For example, browser may define F9 for

BROWSER_ACTION_SUBMIT and F10 to do BROWSER_ACTION_DEFAULT.

Then, no

matter what hotkey that browser defines for submit and default
job,

UEFI driver can disable them by below calls:

EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey

(BROWSER_ACTION_SUBMIT, FormLevel);

EDKII_FORM_BROWSER_EXTENSION2_PROTOCOL.DisableHotkey

(BROWSER_ACTION_DEFAULT, FormLevel);

Then browser will disable the hotkey that is binding to above actions.

UEFI driver does not need to know the specific hotkey to disable.

Instead, UEFI driver disable the action that he does not want to
support

through hotkey.

When UEFI driver provides their own HII button for these actions,
he

would understand what action that they do not want hotkey support.

So, you mean in form open callback to disable hotkey in form level.
Once exit this form, Browser will restore original hotkey. Right?

In fact, UEFI spec defines HII ConfigAccess protocol for data
read and

write.

HII driver should follow this way.

I am not the owner of EDK2 iSCSI driver but I expect that there
might

be some trouble to support hotkey to save iSCSI attempt setting.
My

guess is: iSCSI attempt menu is not one-to-one mapping between
iSCSI

attempt setting and HII option. iSCSI attempt menu is shared
between

multiple network interfaces.

In this design, there might be difficulty to do this through HII

hotkey. And this also applies to secure boot key enrolment case
and

TLS certificate enrolment case in EDK2 drivers.

HII driver doesn't require the display data and save data are 1:1 mapping.

HII driver can convert the display data to the saved data. For
example, the display information is the string, but the saved data
is the

value.

If HII driver doesn't use this way, it can't be handled by Browser.

I think this

is

the expected behavior.

We don't need to introduce new API for it.

Yes it is expected behavior. But from my point of view, as I
mentioned

above, there might be some trouble to support it so HII driver
does

not follow this way. I can see cases in EDK2 driver.

I agree some Edk2 module may not be a good example.



Thanks

Liming

Thanks,

Nickle

Thanks,

Nickle

Thanks

Liming

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