From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.120; helo=mga04.intel.com; envelope-from=star.zeng@intel.com; receiver=edk2-devel@lists.01.org Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C5E5922146720 for ; Thu, 22 Mar 2018 21:48:42 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 21:55:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,348,1517904000"; d="scan'208";a="26338314" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga007.fm.intel.com with ESMTP; 22 Mar 2018 21:55:15 -0700 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 22 Mar 2018 21:55:14 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 22 Mar 2018 21:55:14 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.80]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.226]) with mapi id 14.03.0319.002; Fri, 23 Mar 2018 12:55:13 +0800 From: "Zeng, Star" To: "Ni, Ruiyu" , "edk2-devel@lists.01.org" CC: "Zeng, Star" Thread-Topic: [PATCH] MdeModulePkg/UsbKb: fix shell edit cannot read '!@#$%^&*' characters Thread-Index: AQHTwmHRcq6mZEF1TUK8uRwB6Qns2KPdQWRQ Date: Fri, 23 Mar 2018 04:55:12 +0000 Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103BA72BB3@shsmsx102.ccr.corp.intel.com> References: <20180323044543.157740-1-ruiyu.ni@intel.com> In-Reply-To: <20180323044543.157740-1-ruiyu.ni@intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH] MdeModulePkg/UsbKb: fix shell edit cannot read '!@#$%^&*' characters X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 04:48:43 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reviewed-by: Star Zeng Thanks, Star -----Original Message----- From: Ni, Ruiyu=20 Sent: Friday, March 23, 2018 12:46 PM To: edk2-devel@lists.01.org Cc: Zeng, Star 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 pr= evious example of a Shift Key + "f" key being pressed, the only pertinent d= ata returned would be KeyData.Key.UnicodeChar with the value of "F". UsbKeyboard driver does convert Shift Key + "f" to "F" without the shift st= ate. But it doesn't do the conversion for all printable characters, e.g.: S= hift Key + "1" --> "!". The root cause is today's logic to check whether a character is printable o= r not is as below: if ((KeyDescriptor->AffectedAttribute & EFI_AFFECTED_BY_CAPS_LOCK) !=3D 0) { So it only converts Shift + "a"-"z", but doesn't for Shift + "0"-"9", and S= hift + "["... The patch updates the check logic as below to fix the issue: if ((KeyDescriptor->Unicode !=3D CHAR_NULL) && (KeyDescriptor->ShiftedUnicode !=3D CHAR_NULL) && (KeyDescriptor->Unicode !=3D KeyDescriptor->ShiftedUnicode)) { The above check is TRUE when the character is printable and it's *really* a= ffected by Shift key. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: Star Zeng --- 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/Us= b/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 ch= aracters that // are normally adjusted by shift modifiers. e.g. Shift Key + 'f' ke= y =3D 'F' // - if ((KeyDescriptor->AffectedAttribute & EFI_AFFECTED_BY_CAPS_LOCK) != =3D 0) { + if ((KeyDescriptor->Unicode !=3D CHAR_NULL) && (KeyDescriptor->Shift= edUnicode !=3D CHAR_NULL) && + (KeyDescriptor->Unicode !=3D KeyDescriptor->ShiftedUnicode)) { UsbKeyboardDevice->LeftShiftOn =3D FALSE; UsbKeyboardDevice->RightShiftOn =3D FALSE; } -- 2.16.1.windows.1