How to Interpret ReadKeyStrokeEX Data

* How to Interpret ReadKeyStrokeEX Data
@ 2018-06-01 18:26 Jim.Dailey
  2018-06-04  3:00 ` Ni, Ruiyu
  2018-06-04 17:31 ` Rothman, Michael A
  0 siblings, 2 replies; 12+ messages in thread
From: Jim.Dailey @ 2018-06-01 18:26 UTC (permalink / raw)
  To: ruiyu.ni; +Cc: jaben.carsey, felixp, edk2-devel

(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.

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.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread