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

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

[Ruiyu Ni]

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>
Cc: Star Zeng <star.zeng@intel.com>
---
 MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
index d140311c52..b3b5fb9ff4 100644
--- a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
+++ b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
@@ -1615,7 +1615,8 @@ UsbKeyCodeToEfiInputKey (
       // Need not return associated shift state if a class of printable characters that
       // are normally adjusted by shift modifiers. e.g. Shift Key + 'f' key = 'F'
       //
-      if ((KeyDescriptor->AffectedAttribute & EFI_AFFECTED_BY_CAPS_LOCK) != 0) {
+      if ((KeyDescriptor->Unicode != CHAR_NULL) && (KeyDescriptor->ShiftedUnicode != CHAR_NULL) &&
+          (KeyDescriptor->Unicode != KeyDescriptor->ShiftedUnicode)) {
         UsbKeyboardDevice->LeftShiftOn = FALSE;
         UsbKeyboardDevice->RightShiftOn = FALSE;
       }
-- 
2.16.1.windows.1

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

[Zeng, Star]

Reviewed-by: Star Zeng <star.zeng@intel.com>

Thanks,
Star
-----Original Message-----
From: Ni, Ruiyu 
Sent: Friday, March 23, 2018 12:46 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star <star.zeng@intel.com>
Subject: [PATCH] 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>
Cc: Star Zeng <star.zeng@intel.com>
---
 MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
index d140311c52..b3b5fb9ff4 100644
--- a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
+++ b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
@@ -1615,7 +1615,8 @@ UsbKeyCodeToEfiInputKey (
       // Need not return associated shift state if a class of printable characters that
       // are normally adjusted by shift modifiers. e.g. Shift Key + 'f' key = 'F'
       //
-      if ((KeyDescriptor->AffectedAttribute & EFI_AFFECTED_BY_CAPS_LOCK) != 0) {
+      if ((KeyDescriptor->Unicode != CHAR_NULL) && (KeyDescriptor->ShiftedUnicode != CHAR_NULL) &&
+          (KeyDescriptor->Unicode != KeyDescriptor->ShiftedUnicode)) {
         UsbKeyboardDevice->LeftShiftOn = FALSE;
         UsbKeyboardDevice->RightShiftOn = FALSE;
       }
--
2.16.1.windows.1