commit bc9cea5c29455386b8e5f1c5e97f2a2760e1f271
author Ruiyu Ni <ruiyu.ni@intel.com> Fri Mar 23 12:45:14 2018 +0800
committer Ruiyu Ni <ruiyu.ni@intel.com> Mon Mar 26 09:32:04 2018 +0800
tree 2108a547b9c7d08dd30ca6dfc0ea4a31cb206819
parent d5bc5f1368a0f452589b1633b0586dfe557327e6

MdeModulePkg/UsbKb: fix shell edit cannot read '!@#$%^&*' characters

Commit 5563281fa2b31093a1cbd415553b9264c5136e89
* ShellPkg/[hex]edit: use SimpleTextInEx to read console
changes shell edit and hexedit to read input through SimpleTextInEx.

It exposes a issue in UsbKeyboard driver:
Per UEFI Spec,
When interpreting the data from this function (ReadKeyStrokeEx), 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. So in the previous example of a Shift Key +
"f" key being pressed, the only pertinent data returned would be
KeyData.Key.UnicodeChar with the value of "F".

UsbKeyboard driver does convert Shift Key + "f" to "F" without the
shift state. But it doesn't do the conversion for all printable
characters, e.g.: Shift Key + "1" --> "!".

The root cause is today's logic to check whether a character is
printable or not is as below:
  if ((KeyDescriptor->AffectedAttribute & EFI_AFFECTED_BY_CAPS_LOCK)
      != 0) {

So it only converts Shift + "a"-"z", but doesn't for Shift + "0"-"9",
and Shift + "["...

The patch updates the check logic as below to fix the issue:
  if ((KeyDescriptor->Unicode != CHAR_NULL) &&
      (KeyDescriptor->ShiftedUnicode != CHAR_NULL) &&
      (KeyDescriptor->Unicode != KeyDescriptor->ShiftedUnicode)) {

The above check is TRUE when the character is printable and
it's *really* affected by Shift key.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
(cherry picked from commit dd190645eb43424706eb1709d0032c69a1935d9f)