[ipxe-devel] [PATCH 0/2] Support platforms that do not process the CTRL key

[Michael Brown]

On 24/05/15 21:13, Michael Bazzinotti wrote:
> On Sun May 24 15:31:52 BST 2015, Robin Smidsrød wrote:
>> I'm fairly certain that this patch set will not be accepted. You should
>> instead try to find the root cause for why the CTRL key is not being accepted
>> and fix that. Alternatively (on Mac machines/keyboards) you can use another
>> key (like CMD) and map it to CTRL.
>
>   Fortunately, Grub includes CTRL key shortcuts *and* alternatives *hint
> hint* I
> tested it myself. I took pictures, but I'm failing to upload them. I
> think you
> get the point.
>
> <snip>

Robin is correct.  I'm not going to merge a patch which would have to do 
one of:

- break existing user behaviour (e.g. by changing the existing key usages),

- add behaviour inconsistent with the on-screen instructions (e.g. by 
adding hidden extra key usages besides those mentioned in on-screen 
prompts), or

- generate overly verbose on-screen instructions (e.g. by documenting 
both possible key usages)

without some hard proof that there is a bug in the Apple EFI firmware 
which prohibits the use of Ctrl or any other modifier key.

For example: iPXE currently uses the EFI_SIMPLE_TEXT_INPUT_PROTOCOL to 
read keystrokes, and relies on the UnicodeChar value returned by 
ReadKeyStroke() to obtain the control characters (such as Ctrl-B).  You 
could start by experimenting to find the values returned in both 
UnicodeChar and ScanCode when Ctrl-B is pressed on the Mac.

There is also an EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL which additionally 
provides an EFI_KEY_STATE containing flags for the modifier keys (such 
as Ctrl).  You could use the EFI shell and the "dh" command to see if 
the Apple EFI firmware includes this protocol.

If neither of those approaches gives a usable result, you could 
experiment to see if other modifier keys have some observable effect on 
the values returned by ReadKeyStroke().

Michael