MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
© 2016 - 2024 Red Hat, Inc.