From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=68.232.153.96; helo=esa7.dell-outbound.iphmx.com; envelope-from=jim.dailey@dell.com; receiver=edk2-devel@lists.01.org Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 4B72B20968917 for ; Mon, 4 Jun 2018 07:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1528123588; x=1559659588; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ymHP4KsiYk6mYJRJmnAgKK4Wb4Pm/UAOn+qxVRsXD8k=; b=Te/qWS7zx80Mgvnllrc1XSyFqVCoC1rtIgmSKp8jDTD8KGWarZ29M2TG IC6xwd1qji0HfOTZukF8EA3sx1cNDOIUmUNhjvVQ4J+cGkjl1gxJ3Ms8K inZb/1zACILsRY63gIAEd2khIttmbyhqhewwfNb47ylVg3bJF2pTbnJ/b 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FFAQDjTxVbh8mZ6ERcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQXgQ0oCphggXmUS4F4C4RsAoIRITUXAQIBAQEBAQECAQECEAEBAQo?= =?us-ascii?q?LCQgoL4I1IoJTAQEBAwE6PxACAQgVIRBXAQEEDgUIgxqBeQioRIg/gWiCLYYVg?= =?us-ascii?q?hODZzWFK4UcAphuBwKOW4FEg3iHZoYFixqBQgGCCXCDE4IgDgmOF2+Nf4EZAQE?= X-IPAS-Result: =?us-ascii?q?A2FFAQDjTxVbh8mZ6ERcGgEBAQEBAgEBAQEIAQEBAYQXgQ0?= =?us-ascii?q?oCphggXmUS4F4C4RsAoIRITUXAQIBAQEBAQECAQECEAEBAQoLCQgoL4I1IoJTA?= =?us-ascii?q?QEBAwE6PxACAQgVIRBXAQEEDgUIgxqBeQioRIg/gWiCLYYVghODZzWFK4UcAph?= =?us-ascii?q?uBwKOW4FEg3iHZoYFixqBQgGCCXCDE4IgDgmOF2+Nf4EZAQE?= Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jun 2018 09:46:25 -0500 From: Received: from ausc60pc101.us.dell.com ([143.166.85.206]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jun 2018 20:40:54 +0600 X-LoopCount0: from 10.166.136.213 X-IronPort-AV: E=Sophos;i="5.49,476,1520917200"; d="scan'208";a="1258252900" X-DLP: DLP_GlobalPCIDSS To: CC: , , Thread-Topic: How to Interpret ReadKeyStrokeEX Data Thread-Index: AdP51a/hVUcRd8ZXRbW9WoFUsUlqeAB2jMWgABXhBjA= Date: Mon, 4 Jun 2018 14:46:49 +0000 Message-ID: <5108c0244ffb45ccb0208dd0a1ed2beb@ausx13mps339.AMER.DELL.COM> References: <3e835c29938d49ea8d285385429870ad@ausx13mps339.AMER.DELL.COM> <734D49CCEBEEF84792F5B80ED585239D5BD232B9@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BD232B9@SHSMSX104.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titusconfig: No Restrictions 04051212 x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvIiwiaWQiOiIzN2M4ZmY1OS03MTkyLTRmY2YtODQ1NS00Y2EyMmM4Y2RmYjgiLCJwcm9wcyI6W3sibiI6IkNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJObyBSZXN0cmljdGlvbnMifV19LHsibiI6IlN1YmxhYmVscyIsInZhbHMiOltdfSx7Im4iOiJFeHRlcm5hbENvcnJlc3BvbmRlbmNlIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTYuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ino4SjdkKzlDTVNkZDYyS2ZQWWRhb0RaeUM3aEZQbmhWYktGN2g2V0MrWkE9In0= x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.18.86] MIME-Version: 1.0 Subject: Re: How to Interpret ReadKeyStrokeEX Data X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 14:46:54 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Thanks/Ray > >> From: Jim.Dailey@dell.com >>=20 >> 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: >>=20 >> If the Scan Code is set to 0x00 then the Unicode character is >> valid and should be used. >>=20 >> 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. >Considering there is the other protocol called SimpleTextIn which only ret= urns >Scan Code and Unicode Character. The above statement only says that >consumer should only care one of the fields: Scan Code and Unicode Charact= er. The editor is not using that protocol, but it matters not because your question is my point exactly: when the scan code is zero, nothing else matters except the Unicode character. >> 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): >>=20 >> 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. > >Please also considering an implementation of SimpleTextIn, if "SHIFT + 3" = is >pressed, what Unicode Character should be returned since there is no place >to return the shift state for SimpleTextIn. >I think it should return "#". Again the editor does not use that protocol (if it did, I don't think we'd even be having this discussion!). But to answer your question, of course it should return "#". There is no question about that. And, when it returns "#", it would be wrong to ignore that for any reason. The editor is using the SimpleTextInEx protocol which adds information about the shift state that SimpleTextIn does not supply. The question I am raising is when SimpleTextInEx returns, for example: Scan Code =3D 0 Unicode Char =3D 0x0023 ("#") Shift Information =3D 0x80000001 (right shift pressed) is it correct for the editor to reject this as an invalid key? I say, no, it would be wrong to reject this data because the scan code is 0 and, therefore, the Unicode character is valid and should be used. The change made back on February 12 says, yes, because the shift data is greater than 0x80000000 (i.e. shift state is valid and some "shift" key was pressed). >>> Can you check which keyboard driver are you using? >>> The keyboard driver is expected to translate "SHIFT" + "3" to "#" (with= out >>> 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 maske= d off. As far as I can tell I am using the standard MdeModulePkg USB driver.