Re: How to Interpret ReadKeyStrokeEX Data

[Andrew Fish <afish@apple.com>]

Jim,

The big picture difference is the original SimpleTextIn was the least common denominator with a serial terminal. The Ex version added more info about keyboards, so richer info on modifier keys. 

Thanks,

Andrew Fish

> On Jun 4, 2018, at 7:46 AM, Jim.Dailey@dell.com wrote:
> 
> 
>> Thanks/Ray
>> 
>>> From: Jim.Dailey@dell.com <Jim.Dailey@dell.com>
>>> 
>>> I guess this is a question of UEFI spec interpretation.  In the Console
>>> I/O Protocol description of Version 2.5 of the spec (page 456), it says:
>>> 
>>>    If the Scan Code is set to 0x00 then the Unicode character is
>>>    valid and should be used.
>>> 
>>> To me that clearly says it all.  The shift modifier is a don't care when
>>> the scan code is zero.  And, this change in the shell code seems to be a
>>> violation of that statement.
>> Considering there is the other protocol called SimpleTextIn which only returns
>> Scan Code and Unicode Character. The above statement only says that
>> consumer should only care one of the fields: Scan Code and Unicode Character.
> 
> The editor is not using that protocol, but it matters not because your
> question is my point exactly: when the scan code is zero, nothing else
> matters except the Unicode character.
> 
>>> However, I also see some confusing (and grammatically incorrect) text in
>>> the description of the ReadKeyStrokeEx() function of the simple text in
>>> protocol that I am guessing is related to this change (*emphasis* mine):
>>> 
>>>    When interpreting the data from this function, it should be
>>>    noted that if a class of printable characters that are normally
>>>    *adjusted* by shift modifiers (e.g. Shift Key + "f" key) would
>>>    be presented solely as a KeyData.Key.UnicodeChar without the
>>>    associated shift state.
>> 
>> Please also considering an implementation of SimpleTextIn, if "SHIFT + 3" is
>> pressed, what Unicode Character should be returned since there is no place
>> to return the shift state for SimpleTextIn.
>> I think it should return "#".
> 
> Again the editor does not use that protocol (if it did, I don't think
> we'd even be having this discussion!).  But to answer your question, of
> course it should return "#".  There is no question about that. And, when
> it returns "#", it would be wrong to ignore that for any reason.
> 
> The editor is using the SimpleTextInEx protocol which adds information
> about the shift state that SimpleTextIn does not supply.
> 
> The question I am raising is when SimpleTextInEx returns, for example:
> 
>   Scan Code         = 0
>   Unicode Char      = 0x0023 ("#")
>   Shift Information = 0x80000001 (right shift pressed)
> 
> is it correct for the editor to reject this as an invalid key?
> 
> I say, no, it would be wrong to reject this data because the scan code
> is 0 and, therefore, the Unicode character is valid and should be used.
> 
> The change made back on February 12 says, yes, because the shift data
> is greater than 0x80000000 (i.e. shift state is valid and some "shift"
> key was pressed).
> 
>>>> Can you check which keyboard driver are you using?
>>>> The keyboard driver is expected to translate "SHIFT" + "3" to "#" (without
>>>> Shift state).
>>>> I know that some keyboard driver doesn't do that correctly.
>>>> E.g.: SHIFT + "3" is translated to "#" but the SHIFT state is not masked off.
> 
> As far as I can tell I am using the standard MdeModulePkg USB driver.
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel