Re: How to Interpret ReadKeyStrokeEX Data

["Ni, Ruiyu" <ruiyu.ni@intel.com>]

Thanks/Ray

> -----Original Message-----
> From: Jim.Dailey@dell.com <Jim.Dailey@dell.com>
> Sent: Saturday, June 2, 2018 2:27 AM
> To: Ni, Ruiyu <ruiyu.ni@intel.com>
> Cc: Carsey, Jaben <jaben.carsey@intel.com>; felixp@mail.ru; edk2-
> devel@lists.01.org
> Subject: How to Interpret ReadKeyStrokeEX Data
> 
> (Subject changed)
> 
> 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.

> 
> 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 "#".

> 
> What I think the spec is trying to say here is that for A-Z and a-z,
> the consumer does NOT need to look at the shift state to tell "A" from
> "a", for example, because the Unicode character will be either "A" or
> "a" as appropriate.
> 
> I think saying this is unnecessary simply because the earlier statement
> (If the Scan Code is set to 0x00 then the Unicode character is valid and
> should be used.) covers this case.
> 
> Further, I believe this text applies only to the A-Z keys because their
> corresponding characters are *adjusted* (to upper case) when the shift
> key is pressed. That is, if you adjust "blue" to "BLUE", you have two
> different appearances, but only one meaning.
> 
> However, a "3" is not *adjusted* to a "#"; they are totally different
> characters with different meanings altogether. No C pre-processor would
> be happy seeing: "3ifdef SYMBOL".
> 
> In any case, I see nothing gained by ignoring keys having a zero scan
> code and a valid Unicode character; the spec says that "the Unicode
> character is valid and should be used".
> 
> Regards,
> Jim
> 
> > -----Original Message-----
> > From: Ni, Ruiyu [mailto:ruiyu.ni@intel.com]
> > Sent: Thursday, May 31, 2018 7:19 PM
> > To: Dailey, Jim
> > Cc: Carsey, Jaben; felixp@mail.ru; edk2-devel@lists.01.org
> > Subject: RE: [edk2] [PATCH] ShellPkg/[hex]edit: use SimpleTextInEx to read
> console
> >
> > 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.
> >
> > [Sorry I thought I sent the mail out days ago]
> >
> >> -----Original Message-----
> >> From: Jim.Dailey@dell.com [mailto:Jim.Dailey@dell.com]
> >> Sent: Wednesday, May 23, 2018 3:01 AM
> >> To: Ni, Ruiyu <ruiyu.ni@intel.com>
> >> Cc: Carsey, Jaben <jaben.carsey@intel.com>; felixp@mail.ru; edk2-
> >> devel@lists.01.org
> >> Subject: RE: [edk2] [PATCH] ShellPkg/[hex]edit: use SimpleTextInEx to
> read
> >> console
> >>
> >> Ray,
> >>
> >> The patch in the message below was applied to the tree on 12 Feb this
> year
> >> (5563281fa2b31093a1cbd415553b9264c5136e89).
> >>
> >> Part of the change to MainTextEditor.c causes an issue where I cannot
> enter (at
> >> least some) shifted punctuation.  For example, after this check in I cannot
> edit a
> >> shell script and create a comment because I cannot enter the "#"
> character.
> >> When I try to type "#", the status bar simply shows "Unknown Command".
> >>
> >> I don't really understand the change, but if in the MainEditorKeyInput
> function in
> >> file MainTextEditor.c I delete the "NoShiftState" check from the first "else
> if"
> >> below:
> >>
> >> +        //
> >> +        // dispatch to different components' key handling function
> >> +        //
> >> +        if (EFI_NOT_FOUND != MenuBarDispatchControlHotKey(&KeyData))
> {
> >> +          Status = EFI_SUCCESS;
> >> +        } else if (NoShiftState && ((KeyData.Key.ScanCode == SCAN_NULL)
> ||
> >> ((KeyData.Key.ScanCode >= SCAN_UP) && (KeyData.Key.ScanCode <=
> >> SCAN_PAGE_DOWN)))) {
> >> +          Status = FileBufferHandleInput (&KeyData.Key);
> >> +        } else if (NoShiftState && (KeyData.Key.ScanCode >= SCAN_F1) &&
> >> (KeyData.Key.ScanCode <= SCAN_F12)) {
> >> +          Status = MenuBarDispatchFunctionKey (&KeyData.Key);
> >> +        } else {
> >> +          StatusBarSetStatusString (L"Unknown Command");
> >> +          FileBufferMouseNeedRefresh = FALSE;
> >> +        }
> >>
> >> then I am able to enter "#" and other characters that I previously was
> unable to
> >> enter.
> >>
> >> Can you have a look at this?  I assume any shell binary built with this
> change will
> >> have a similar issue.
> >>
> >> Thanks,
> >> Jim
> >>
> >>> -----Original Message-----
> >>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
> Of Ruiyu
> >>> Ni
> >>> Sent: Monday, February 12, 2018 9:34 AM
> >>> To: edk2-devel@lists.01.org
> >>> Cc: Jaben Carsey; Felix
> >>> Subject: [edk2] [PATCH] ShellPkg/[hex]edit: use SimpleTextInEx to read
> console
> >>>
> >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=682
> >>>
> >>> Edit and HexEdit commands assume that SimpleTxtIn translates
> >>> Ctrl+<Alpha-Key> key combinations into Unicode control characters
> >>> (0x1-0x1A).
> >>>
> >>> Such translation does not seem to be required by the UEFI spec.
> >>> Shell should not rely on implementation specific behavior.
> >>> It should instead use SimpleTextInEx to read Ctrl+<Alpha-Key> key
> combinations.
> >>>
> >>> The patch changes edit and hexedit to only consumes SimpleTextInEx.
> >>>
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
> >>> Reported-by: Felix <felixp@mail.ru>
> >>> Cc: Felix <felixp@mail.ru>
> >>> Cc: Jaben Carsey <jaben.carsey@intel.com>
> >>> ---
> >>>  .../Edit/MainTextEditor.c                          | 135 +++++++++-----
> >>>  .../Edit/TextEditorTypes.h                         |  21 ++-
> >>>  .../UefiShellDebug1CommandsLib/EditInputBar.c      |  34 +++-
> >>>  .../UefiShellDebug1CommandsLib/EditInputBar.h      |   6 +-
> >>>  .../UefiShellDebug1CommandsLib/EditMenuBar.c       |  38 +++-
> >>>  .../UefiShellDebug1CommandsLib/EditMenuBar.h       |   6 +-
> >>>  .../HexEdit/HexEditorTypes.h                       |  25 +--
> >>>  .../HexEdit/MainHexEditor.c                        | 205 +++++++++++++--------
> >>>  8 files changed, 309 insertions(+), 161 deletions(-)
> >>>
> >>> ---------8<----- clip ----->8--------
> >>>
> >>> --
> >>> 2.16.1.windows.1
> >>>
> >>> _______________________________________________
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel