>Thanks/Ray
>
>> From: [email protected] <[email protected]>
>>
>> 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
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
