Re: [PATCH] Make CTRL and ALT keys work as expected on EFI systems (version 5).

[Peter Jones]

On Sat, Oct 10, 2015 at 09:48:58PM +0300, Andrei Borzenkov wrote:

Sorry - realized I should have addressed your question and said one more
thing.

> Are there open issues with this patch? Is it used by Fedora? The part about
> SHIFT state bothers me, what happens for non-ASCII printable characters?
> UEFI spec is extremely vague here.

As for non-ASCII printables, I have no idea.  I literally couldn't find
a keyboard that generated any around my office.  Even my European and
Japanese coworkers don't seem to have them.  That said, given the
comment here:
 
https://github.com/vathpela/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c#L481
and the two tables here:
 
https://github.com/vathpela/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c#L36
 
https://github.com/vathpela/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c#L149
my guess is that on the vast majority of systems they just don't produce
any keypress.  We could do things like make right-alt act like AltGr and
synthesize them ourselves, of course, if there's a significant need.
(Awesomely, AltGr is defined by the EFI modifier list but not mapped
from the USB bits.  Which probably doesn't matter, since nobody uses
keyboards with AltGr keys.)

> As currently there is no way to actually input Ctrl-X or similar this is
> needed. It may also allow us to actually implement keystatus on EFI.

One issue related to implementing keystatus is the "Windows Fast Boot"
feature, enabled by default in nearly all "client" machines now.  (It's
a Windows logo requirement.)  This feature basically says not to probe
USB and the like by default.  So on any machines where your input
device is USB, what winds up happening is that it probes for HII devices
when you call ->read_key_stroke() or ->read_key_stroke_ex() the first
time.  Depending on the hardware configuration, how many devices are
plugged in, how many hubs away the keyboard is, etc., this can take a
surprisingly long period of time.  (FWIW, I *think*
register_key_notify() and set_key_state() will also trigger the driver
loading and probing on most implementations.)

For practical purposes right now, this is pretty much okay with how most
people are using GRUB.  But if somebody wanted to implement "don't show
menus unless the user requested it before the reboot, or the last boot
failed" in their grub config file, then the user gets a much quicker
boot experience if we don't scan the keyboard.

-- 
        Peter