From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=68.232.149.214; helo=esa4.dell-outbound.iphmx.com; envelope-from=jim.dailey@dell.com; receiver=edk2-devel@lists.01.org Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 4CF7C210D6904 for ; Fri, 1 Jun 2018 11:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1527877611; x=1559413611; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=i2MWZs2YgOK1wlf+tNKNNkA/OE6xsYiBfMY9rRjoFco=; b=tARXNIXVDBz1Po1pLR0vMyPnvxDr3J/AJxHimj4l4b1Xk4wqa8CgF/4s rPRqSDEu5ylKKMFmJOsl6x4GXPR/6eA/hZJgQNuEOtHFLrSnhkuTQuEt0 YdKbkCW6FX2r/AFUBpf3hFr/2b3tGVehYl3d6ov2HB3Z6Vv95i/LLQ/Xi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FMAADbjhFbh2Ka6ERcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQXDn8oCotxjGeBeYFvkl2BeAsYCwuEPgKCBiE0GAECAQEBAQE?= =?us-ascii?q?BAgEBAhABAQEKCwkIKCMMgjUiEXoBAQEBAQEBAQEjKgINYwEBAQEEASUTMgILD?= =?us-ascii?q?AYBGQQBAR8JLgEeCQkBBA4FCIMaAoFnAxUPqFYzhwgVgSSBYwWCLIYTghODZ4N?= =?us-ascii?q?GAQMBF4EmAQElhU0CmGwHAoE5hDOFFYNYgUSGWoR/iXOEK4J7gUGCC3BQgkOCL?= =?us-ascii?q?og3K4U+bwGNMYEfgRkBAQ?= X-IPAS-Result: =?us-ascii?q?A2FMAADbjhFbh2Ka6ERcGQEBAQEBAQEBAQEBAQcBAQEBAYQ?= =?us-ascii?q?XDn8oCotxjGeBeYFvkl2BeAsYCwuEPgKCBiE0GAECAQEBAQEBAgEBAhABAQEKC?= =?us-ascii?q?wkIKCMMgjUiEXoBAQEBAQEBAQEjKgINYwEBAQEEASUTMgILDAYBGQQBAR8JLgE?= =?us-ascii?q?eCQkBBA4FCIMaAoFnAxUPqFYzhwgVgSSBYwWCLIYTghODZ4NGAQMBF4EmAQElh?= =?us-ascii?q?U0CmGwHAoE5hDOFFYNYgUSGWoR/iXOEK4J7gUGCC3BQgkOCLog3K4U+bwGNMYE?= =?us-ascii?q?fgRkBAQ?= Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2018 13:26:47 -0500 From: Received: from ausxippc110.us.dell.com ([143.166.85.200]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2018 00:26:47 +0600 X-LoopCount0: from 10.166.136.210 X-IronPort-AV: E=Sophos;i="5.49,467,1520917200"; d="scan'208";a="660032486" X-DLP: DLP_GlobalPCIDSS To: CC: , , Thread-Topic: How to Interpret ReadKeyStrokeEX Data Thread-Index: AdP51a/hVUcRd8ZXRbW9WoFUsUlqeA== Date: Fri, 1 Jun 2018 18:26:46 +0000 Message-ID: <3e835c29938d49ea8d285385429870ad@ausx13mps339.AMER.DELL.COM> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titusconfig: No Restrictions 04051212 x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvIiwiaWQiOiI2YmMwODM2YS01MmZkLTRmZDMtYmU3My02OWU2YjEyM2FiYzgiLCJwcm9wcyI6W3sibiI6IkNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJObyBSZXN0cmljdGlvbnMifV19LHsibiI6IlN1YmxhYmVscyIsInZhbHMiOltdfSx7Im4iOiJFeHRlcm5hbENvcnJlc3BvbmRlbmNlIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTYuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6Illqc3dKNWRFUXFVaE54UHZKZlg1U01HcWxzeUhPcnF0RlFjTXYxTUJLNUU9In0= x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.242.75] MIME-Version: 1.0 Subject: 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: Fri, 01 Jun 2018 18:26:51 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Subject changed) 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: If the Scan Code is set to 0x00 then the Unicode character is valid and should be used. 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. 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): 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. What I think the spec is trying to say here is that for A-Z and a-z, the consumer does NOT need to look at the shift state to tell "A" from "a", for example, because the Unicode character will be either "A" or "a" as appropriate. I think saying this is unnecessary simply because the earlier statement (If the Scan Code is set to 0x00 then the Unicode character is valid and should be used.) covers this case. Further, I believe this text applies only to the A-Z keys because their corresponding characters are *adjusted* (to upper case) when the shift key is pressed. That is, if you adjust "blue" to "BLUE", you have two different appearances, but only one meaning. However, a "3" is not *adjusted* to a "#"; they are totally different characters with different meanings altogether. No C pre-processor would be happy seeing: "3ifdef SYMBOL". In any case, I see nothing gained by ignoring keys having a zero scan code and a valid Unicode character; the spec says that "the Unicode character is valid and should be used". Regards, Jim > -----Original Message----- > From: Ni, Ruiyu [mailto:ruiyu.ni@intel.com]=20 > Sent: Thursday, May 31, 2018 7:19 PM > To: Dailey, Jim > Cc: Carsey, Jaben; felixp@mail.ru; edk2-devel@lists.01.org > Subject: RE: [edk2] [PATCH] ShellPkg/[hex]edit: use SimpleTextInEx to rea= d console >=20 > Can you check which keyboard driver are you using? > The keyboard driver is expected to translate "SHIFT" + "3" to "#" (withou= t 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 masked = off. >=20 > [Sorry I thought I sent the mail out days ago] > >> -----Original Message----- >> From: Jim.Dailey@dell.com [mailto:Jim.Dailey@dell.com] >> Sent: Wednesday, May 23, 2018 3:01 AM >> To: Ni, Ruiyu >> Cc: Carsey, Jaben ; felixp@mail.ru; edk2- >> devel@lists.01.org >> Subject: RE: [edk2] [PATCH] ShellPkg/[hex]edit: use SimpleTextInEx to re= ad >> console >>=20 >> Ray, >>=20 >> The patch in the message below was applied to the tree on 12 Feb this ye= ar >> (5563281fa2b31093a1cbd415553b9264c5136e89). >>=20 >> Part of the change to MainTextEditor.c causes an issue where I cannot en= ter (at >> least some) shifted punctuation. For example, after this check in I can= not edit a >> shell script and create a comment because I cannot enter the "#" charact= er. >> When I try to type "#", the status bar simply shows "Unknown Command". >>=20 >> I don't really understand the change, but if in the MainEditorKeyInput f= unction in >> file MainTextEditor.c I delete the "NoShiftState" check from the first "= else if" >> below: >>=20 >> + // >> + // dispatch to different components' key handling function >> + // >> + if (EFI_NOT_FOUND !=3D MenuBarDispatchControlHotKey(&KeyData)) = { >> + Status =3D EFI_SUCCESS; >> + } else if (NoShiftState && ((KeyData.Key.ScanCode =3D=3D SCAN_N= ULL) || >> ((KeyData.Key.ScanCode >=3D SCAN_UP) && (KeyData.Key.ScanCode <=3D >> SCAN_PAGE_DOWN)))) { >> + Status =3D FileBufferHandleInput (&KeyData.Key); >> + } else if (NoShiftState && (KeyData.Key.ScanCode >=3D SCAN_F1) = && >> (KeyData.Key.ScanCode <=3D SCAN_F12)) { >> + Status =3D MenuBarDispatchFunctionKey (&KeyData.Key); >> + } else { >> + StatusBarSetStatusString (L"Unknown Command"); >> + FileBufferMouseNeedRefresh =3D FALSE; >> + } >>=20 >> then I am able to enter "#" and other characters that I previously was u= nable to >> enter. >>=20 >> Can you have a look at this? I assume any shell binary built with this = change will >> have a similar issue. >>=20 >> Thanks, >> Jim >>=20 >>> -----Original Message----- >>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of = Ruiyu >>> Ni >>> Sent: Monday, February 12, 2018 9:34 AM >>> To: edk2-devel@lists.01.org >>> Cc: Jaben Carsey; Felix >>> Subject: [edk2] [PATCH] ShellPkg/[hex]edit: use SimpleTextInEx to read = console >>>=20 >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D682 >>>=20 >>> Edit and HexEdit commands assume that SimpleTxtIn translates >>> Ctrl+ key combinations into Unicode control characters >>> (0x1-0x1A). >>>=20 >>> Such translation does not seem to be required by the UEFI spec. >>> Shell should not rely on implementation specific behavior. >>> It should instead use SimpleTextInEx to read Ctrl+ key combi= nations. >>>=20 >>> The patch changes edit and hexedit to only consumes SimpleTextInEx. >>>=20 >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Ruiyu Ni >>> Reported-by: Felix >>> Cc: Felix >>> Cc: Jaben Carsey >>> --- >>> .../Edit/MainTextEditor.c | 135 +++++++++----= - >>> .../Edit/TextEditorTypes.h | 21 ++- >>> .../UefiShellDebug1CommandsLib/EditInputBar.c | 34 +++- >>> .../UefiShellDebug1CommandsLib/EditInputBar.h | 6 +- >>> .../UefiShellDebug1CommandsLib/EditMenuBar.c | 38 +++- >>> .../UefiShellDebug1CommandsLib/EditMenuBar.h | 6 +- >>> .../HexEdit/HexEditorTypes.h | 25 +-- >>> .../HexEdit/MainHexEditor.c | 205 +++++++++++++= -------- >>> 8 files changed, 309 insertions(+), 161 deletions(-) >>>=20 >>> ---------8<----- clip ----->8-------- >>>=20 >>> -- >>> 2.16.1.windows.1 >>>=20 >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel