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, [email protected] wrote: > > >> 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
