From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.32; helo=mail-in22.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 509932112501A for ; Wed, 6 Jun 2018 06:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528291817; x=2392205417; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tRLbf19w6zZW4vc9DcW2UzoDpHmJq5V7kudrBOzuJDI=; b=IbdWqIzkNWPSoxWl5gFa6rQq/rWZNPIiwkHbEsfsojfmXBzxGnXQSStTyKfXjBn0 MQGgb7A3KELDbPkJFCD0vc1Ciiqo+RHvCa/5hhlcNGaDkNb0HDypj6ExktATmNp7 Qaw0eOZKrsg0mmYHX2iFzykUe27YpMXOgFcRa7ER/HfPX9lbfiAG03YwITITidEO w6yRLoCbm0ZNtdLp2EGk9r7bz19ky0K7JRhe0SnKPrjvfWpIJ8dh0Kc7AIUFfZkn Wd4y3uxxT72mRYEFA6v5rQBaTEh235G5+t4kzF4reTaL1SXGsmuH6MqrG5Rz9LYF G6i7zlJPOGBRBVPbj9+X8w==; X-AuditID: 11ab0216-c97ff70000002f11-ce-5b17e1e89f9c Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 70.C5.12049.8E1E71B5; Wed, 6 Jun 2018 06:30:17 -0700 (PDT) MIME-version: 1.0 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9W0077OLIGXA10@mr2-mtap-s01.rno.apple.com>; Wed, 06 Jun 2018 06:30:16 -0700 (PDT) Received: from [17.234.124.91] (unknown [17.234.124.91]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9W00JLWLIEAW20@nwk-mmpp-sz12.apple.com>; Wed, 06 Jun 2018 06:30:16 -0700 (PDT) X-Va-A: X-Va-T-CD: bd6e6fbb691cce019cecd961ae215554 X-Va-E-CD: 16f719678d796be39407241f4bd0d878 X-Va-R-CD: 9dbbece55e46eedc069bff5a3d7f165a X-Va-CD: 0 X-Va-ID: 232febc8-20b8-490a-90b9-aa6e7c84bbb2 X-V-A: X-V-T-CD: 97c0f9b28525a040a6886b84b46c7c8b X-V-E-CD: 16f719678d796be39407241f4bd0d878 X-V-R-CD: 9dbbece55e46eedc069bff5a3d7f165a X-V-CD: 0 X-V-ID: ea24c383-1b29-48aa-b6f0-36baa8feba8e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-06_06:,, signatures=0 Sender: afish@apple.com From: Andrew Fish In-reply-to: Date: Wed, 06 Jun 2018 06:30:14 -0700 Cc: Michael Rothmam , "Carsey, Jaben" , ruiyu.ni@intel.com, edk2-devel@lists.01.org, felixp@mail.ru Message-id: <2878CB99-D229-46C1-9874-CA7C3032D0C2@apple.com> References: <3e835c29938d49ea8d285385429870ad@ausx13mps339.AMER.DELL.COM> To: Jim.Dailey@dell.com X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNIsWRmVeSWpSXmKPExsUiuPlRq+7Lh+LRBpc28FnsOXSU2WLSgwPs Fhub/rBaTPpYadHW2sNo8bJnNbsDm8ekmTOYPRbvecnk0T37H4vHlLlHWANYorhsUlJzMstS i/TtErgyJk9sYyrYmF3x+9M75gbGz2FdjJwcEgImEms37GfuYuTiEBI4yCTx99QGRpAEr4Cg xI/J91i6GDk4mAXUJaZMyYWoWc8ksfPCLzYIZyKTxO+e90wQk9gl/vzawQJha0ts2HAOzp7T eZkVxn64+S0bhM0lsWDraai4rkTblg5GCJtNYv2JJVAztSTWTHvCDmPvXPeUDcbe178HKs4p cf7LRHaQQyUEdCRuPGGGMLMlrn/mAqkQFhCXeHdmEzOEbSlx+yXERDYBZYkV8z+A2ZwCXhJ3 dr0Fq2ERUJV4seEbI8iLzAJzGCW6Xt0FO40Z6Pwn7y6wgsznFbCR+LxfFRIMc5kkvs27Bnay CNCy3WdeQp2mJPF/1xHmCYxys5CCdBYiSGchmbqAkXkVo3BuYmaObmaekZFeYkFBTqpecn7u JkZQaljNJLaD8d5rw0OMAhyMSjy8K7rFooVYE8uKK3MPMUpzsCiJ837cBRQSSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXA2PCsOc/BSt3caPXcqNmhIskZ8y9NXlN35/lL72+czzsC7Svu/99d osjOmZ7/6dPMA4ccVzy+pu+U/tXjVN/ULSKbE+717DBhv30tyCmqaUdt9imjfbzWvTMb5hw2 W7PlwrTjVYqOmqbPpl3xKFU/26IpMnmBre2S6xu/rm9fL8fnP/1y7fQ3zkosxRmJhlrMRcWJ APmiHk/uAgAA 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: Wed, 06 Jun 2018 13:30:18 -0000 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Jun 6, 2018, at 6:03 AM, Jim.Dailey@dell.com wrote: >=20 > Thanks, Mike. I figured that out yesterday. >=20 > I think the only problem now is that any shell built with the original = change to edit will not work as expected if it is run on a system whose = BIOS was created before the second change was made (i.e. pretty much = every existing UEFI BIOS in the world!). >=20 > Since the shell is a stand-alone tool that is not necessarily tied to = any particular machine, I think that it is likely that more than a few = people may run into this problem in the future. >=20 Jim, You bring up a really good issue about the compatibility targets for the = EFI Shell.I'll bring this up at the next Tianocore Stewards meeting so = we can put some more thought into what the right thing to do is.=20 Thanks, Andrew Fish > Regards, > Jim >=20 > -----Original Message----- > From: Rothman, Michael A [mailto:michael.a.rothman@intel.com]=20 > Sent: Tuesday, June 5, 2018 10:38 PM > To: Rothman, Michael A; Dailey, Jim; Ni, Ruiyu > Cc: Carsey, Jaben; edk2-devel@lists.01.org; felixp@mail.ru > Subject: RE: How to Interpret ReadKeyStrokeEX Data >=20 > Jim, >=20 > I think the problem you're seeing is that the USB keyboard driver = you're using is downrev and needs to be updated. >=20 > If you look at = https://github.com/tianocore/edk2/commit/dd190645eb43424706eb1709d0032c69a= 1935d9f there was a fix checked in to address exactly the issue you're = running into. It's basically a symptom of running a new shell without a = correspondingly updated keyboard driver. The new shell in effect exposed = a latent bug. >=20 > Hope that helps. >=20 > Thanks, > Mike Rothman=20 > (=E8=BF=88=E5=85=8B =E7=BD=97=E6=96=AF=E6=9B=BC / =E0=A4=AE=E0=A4=BE=E0=A4= =87=E0=A4=95=E0=A4=B2 =E0=A4=B0=E0=A5=8B=E0=A4=A5=E0=A5=8D=E0=A4=AE=E0=A5=87= =E0=A4=A8=E0=A5=8D / =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=A0=D0=BE=D1=82= =D0=BC=D0=B0=D0=BD / =D7=9E=D7=A9=D7=94 =D7=A8=D7=95=D7=98=D7=9E=D7=9F) > =D7=A8=D7=95=D7=A2=D7=94 =D7=A2=D7=99=D7=A7=D7=A8=D7=99 =D7=A9=D7=9C = =D7=97=D7=AA=D7=95=D7=9C=D7=99=D7=9D >=20 > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of = Rothman, Michael A > Sent: Monday, June 4, 2018 10:31 AM > To: Jim.Dailey@dell.com; Ni, Ruiyu > Cc: Carsey, Jaben ; edk2-devel@lists.01.org; = felixp@mail.ru > Subject: Re: [edk2] How to Interpret ReadKeyStrokeEX Data >=20 > Since I'm largely the person who might be to blame for the language = and intent here and I=E2=80=99ll focus on the spec-related item. See my = comments below. >=20 >=20 >=20 > Thanks, >=20 > Mike Rothman >=20 > (=E8=BF=88=E5=85=8B =E7=BD=97=E6=96=AF=E6=9B=BC / =E0=A4=AE=E0=A4=BE=E0=A4= =87=E0=A4=95=E0=A4=B2 =E0=A4=B0=E0=A5=8B=E0=A4=A5=E0=A5=8D=E0=A4=AE=E0=A5=87= =E0=A4=A8=E0=A5=8D / =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=A0=D0=BE=D1=82= =D0=BC=D0=B0=D0=BD / =D7=9E=D7=A9=D7=94 =D7=A8=D7=95=D7=98=D7=9E=D7=9F) >=20 > =D7=A8=D7=95=D7=A2=D7=94 =D7=A2=D7=99=D7=A7=D7=A8=D7=99 =D7=A9=D7=9C = =D7=97=D7=AA=D7=95=D7=9C=D7=99=D7=9D >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of = Jim.Dailey@dell.com > Sent: Friday, June 1, 2018 11:27 AM > To: Ni, Ruiyu > Cc: Carsey, Jaben ; edk2-devel@lists.01.org; = felixp@mail.ru > Subject: [edk2] How to Interpret ReadKeyStrokeEX Data >=20 >=20 >=20 > (Subject changed) >=20 >=20 >=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 >=20 >=20 > If the Scan Code is set to 0x00 then the Unicode character is >=20 > valid and should be used. >=20 >=20 >=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. >=20 >=20 >=20 > 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 >=20 >=20 > When interpreting the data from this function, it should be >=20 > noted that if a class of printable characters that are normally >=20 > *adjusted* by shift modifiers (e.g. Shift Key + "f" key) would >=20 > be presented solely as a KeyData.Key.UnicodeChar without the >=20 > associated shift state. >=20 >=20 >=20 > 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. >=20 >=20 >=20 > n No, it is any key that would create a displayable character that = adjusts based on the shift state. Realize that the users of = ReadKeyStroke/ReadKeyStrokeEx fall back to a common denominator of Scan = Code or Unicode Character. So if someone types a shift 4, the underlying = keyboard layout that the keyboard driver controls would dictate how that = gets translated. On my keyboard in the US it turns into a =E2=80=9C$=E2=80= =9D symbol, while someone in Europe may very well have a = software-defined keyboard layout which translates the same keystroke to = a =E2=80=9C=E2=82=AC=E2=80=9D symbol. That of course applies to the many = characters you specified (A-F, a-f) and many others. >=20 > n The text above is intended to imply what it says, =E2=80=9Ca class = of printable characters =E2=80=A6 would be presented solely as a = KeyData.Key.UnicodeChar without the associated shift state. This makes = consumers of both the Ex and Non-Ex variant of ReadKeyStroke able to use = the same logic to test for any shiftable characters by simply looking at = the Unicode value. I=E2=80=99d note the shift and toggle states (which = are only available on Ex) are there not so much for interpreting the = translated key but to maximize flexibility associated with keyboard = mapping as a UEFI application. >=20 >=20 >=20 > 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. >=20 >=20 >=20 > 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. >=20 >=20 >=20 > 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". >=20 >=20 >=20 > 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". >=20 >=20 >=20 > Regards, >=20 > Jim >=20 >=20 >=20 >> -----Original Message----- >=20 >> From: Ni, Ruiyu [mailto:ruiyu.ni@intel.com] >=20 >> Sent: Thursday, May 31, 2018 7:19 PM >=20 >> To: Dailey, Jim >=20 >> Cc: Carsey, Jaben; felixp@mail.ru; = edk2-devel@lists.01.org >=20 >> Subject: RE: [edk2] [PATCH] ShellPkg/[hex]edit: use SimpleTextInEx to >=20 >> read console >=20 >>=20 >=20 >> Can you check which keyboard driver are you using? >=20 >> The keyboard driver is expected to translate "SHIFT" + "3" to "#" = (without Shift state). >=20 >> I know that some keyboard driver doesn't do that correctly. >=20 >> E.g.: SHIFT + "3" is translated to "#" but the SHIFT state is not = masked off. >=20 >>=20 >=20 >> [Sorry I thought I sent the mail out days ago] >=20 >>=20 >=20 >>> -----Original Message----- >=20 >>> From: Jim.Dailey@dell.com = [mailto:Jim.Dailey@dell.com] >=20 >>> Sent: Wednesday, May 23, 2018 3:01 AM >=20 >>> To: Ni, Ruiyu > >=20 >>> Cc: Carsey, Jaben = >; = felixp@mail.ru; edk2- >=20 >>> devel@lists.01.org >=20 >>> Subject: RE: [edk2] [PATCH] ShellPkg/[hex]edit: use SimpleTextInEx = to >=20 >>> read console >=20 >>>=20 >=20 >>> Ray, >=20 >>>=20 >=20 >>> The patch in the message below was applied to the tree on 12 Feb = this >=20 >>> year (5563281fa2b31093a1cbd415553b9264c5136e89). >=20 >>>=20 >=20 >>> Part of the change to MainTextEditor.c causes an issue where I = cannot >=20 >>> enter (at least some) shifted punctuation. For example, after this >=20 >>> check in I cannot edit a shell script and create a comment because I = cannot enter the "#" character. >=20 >>> When I try to type "#", the status bar simply shows "Unknown = Command". >=20 >>>=20 >=20 >>> I don't really understand the change, but if in the >=20 >>> MainEditorKeyInput function in file MainTextEditor.c I delete the = "NoShiftState" check from the first "else if" >=20 >>> below: >=20 >>>=20 >=20 >>> + // >=20 >>> + // dispatch to different components' key handling function >=20 >>> + // >=20 >>> + if (EFI_NOT_FOUND !=3D = MenuBarDispatchControlHotKey(&KeyData)) { >=20 >>> + Status =3D EFI_SUCCESS; >=20 >>> + } else if (NoShiftState && ((KeyData.Key.ScanCode =3D=3D >=20 >>> + SCAN_NULL) || >=20 >>> ((KeyData.Key.ScanCode >=3D SCAN_UP) && (KeyData.Key.ScanCode <=3D >=20 >>> SCAN_PAGE_DOWN)))) { >=20 >>> + Status =3D FileBufferHandleInput (&KeyData.Key); >=20 >>> + } else if (NoShiftState && (KeyData.Key.ScanCode >=3D = SCAN_F1) >=20 >>> + && >=20 >>> (KeyData.Key.ScanCode <=3D SCAN_F12)) { >=20 >>> + Status =3D MenuBarDispatchFunctionKey (&KeyData.Key); >=20 >>> + } else { >=20 >>> + StatusBarSetStatusString (L"Unknown Command"); >=20 >>> + FileBufferMouseNeedRefresh =3D FALSE; >=20 >>> + } >=20 >>>=20 >=20 >>> then I am able to enter "#" and other characters that I previously >=20 >>> was unable to enter. >=20 >>>=20 >=20 >>> Can you have a look at this? I assume any shell binary built with >=20 >>> this change will have a similar issue. >=20 >>>=20 >=20 >>> Thanks, >=20 >>> Jim >=20 >>>=20 >=20 >>>> -----Original Message----- >=20 >>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf >=20 >>>> Of Ruiyu Ni >=20 >>>> Sent: Monday, February 12, 2018 9:34 AM >=20 >>>> To: edk2-devel@lists.01.org >=20 >>>> Cc: Jaben Carsey; Felix >=20 >>>> Subject: [edk2] [PATCH] ShellPkg/[hex]edit: use SimpleTextInEx to >=20 >>>> read console >=20 >>>>=20 >=20 >>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D682 >=20 >>>>=20 >=20 >>>> Edit and HexEdit commands assume that SimpleTxtIn translates >=20 >>>> Ctrl+ key combinations into Unicode control characters >=20 >>>> (0x1-0x1A). >=20 >>>>=20 >=20 >>>> Such translation does not seem to be required by the UEFI spec. >=20 >>>> Shell should not rely on implementation specific behavior. >=20 >>>> It should instead use SimpleTextInEx to read Ctrl+ key = combinations. >=20 >>>>=20 >=20 >>>> The patch changes edit and hexedit to only consumes SimpleTextInEx. >=20 >>>>=20 >=20 >>>> Contributed-under: TianoCore Contribution Agreement 1.1 >=20 >>>> Signed-off-by: Ruiyu Ni = > >=20 >>>> Reported-by: Felix > >=20 >>>> Cc: Felix > >=20 >>>> Cc: Jaben Carsey = > >=20 >>>> --- >=20 >>>> .../Edit/MainTextEditor.c | 135 = +++++++++----- >=20 >>>> .../Edit/TextEditorTypes.h | 21 ++- >=20 >>>> .../UefiShellDebug1CommandsLib/EditInputBar.c | 34 +++- >=20 >>>> .../UefiShellDebug1CommandsLib/EditInputBar.h | 6 +- >=20 >>>> .../UefiShellDebug1CommandsLib/EditMenuBar.c | 38 +++- >=20 >>>> .../UefiShellDebug1CommandsLib/EditMenuBar.h | 6 +- >=20 >>>> .../HexEdit/HexEditorTypes.h | 25 +-- >=20 >>>> .../HexEdit/MainHexEditor.c | 205 = +++++++++++++-------- >=20 >>>> 8 files changed, 309 insertions(+), 161 deletions(-) >=20 >>>>=20 >=20 >>>> ---------8<----- clip ----->8-------- >=20 >>>>=20 >=20 >>>> -- >=20 >>>> 2.16.1.windows.1 >=20 >>>>=20 >=20 >>>> _______________________________________________ >=20 >>>> edk2-devel mailing list >=20 >>>> edk2-devel@lists.01.org >=20 >>>> https://lists.01.org/mailman/listinfo/edk2-devel >=20 >=20 >=20 > _______________________________________________ >=20 > edk2-devel mailing list >=20 > edk2-devel@lists.01.org >=20 > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel