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 Sent from my iPad > On Jun 4, 2018, at 9:02 AM, "[email protected]" <[email protected]> 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:[email protected]] On Behalf Of > Dailey, Jim > Sent: Monday, June 4, 2018 11:00 AM > To: [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [edk2] How to Interpret ReadKeyStrokeEX Data > > Dell - Internal Use - Confidential <=== THIS IS BOGUS !! > >> From: [email protected] [mailto:[email protected]] >> >> 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 > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
