Re: How to Interpret ReadKeyStrokeEX Data

["Carsey, Jaben" <jaben.carsey@intel.com>]

Jim,

I think I see what you mean.  If scan code is 0, then don’t test the shift state and just use the character raw?

Jaben
> On Jun 4, 2018, at 9:02 AM, "Jim.Dailey@dell.com" <Jim.Dailey@dell.com> wrote:
> 
> Please disregard the stupid "Confidential" line that our email tool
> adds but hides from me when I send text. :-(
> 
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Dailey, Jim
> Sent: Monday, June 4, 2018 11:00 AM
> To: afish@apple.com
> Cc: ruiyu.ni@intel.com; jaben.carsey@intel.com; edk2-devel@lists.01.org; felixp@mail.ru
> Subject: Re: [edk2] How to Interpret ReadKeyStrokeEX Data
> 
> Dell - Internal Use - Confidential   <=== THIS IS BOGUS !!
> 
>> From: afish@apple.com [mailto:afish@apple.com] 
>> 
>> 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.
> 
> I get that.  But I fail to see how that affects SimpleTextInEx behavior or
> what the UEFI spec has to say about it.
> 
> As I said earlier, the question I am raising is when SimpleTextInEx returns
> something like:
> 
>   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.
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel