From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.31; helo=mga06.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 C9E3F2110C833 for ; Sun, 3 Jun 2018 20:00:58 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2018 20:00:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,475,1520924400"; d="scan'208";a="45009023" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga008.fm.intel.com with ESMTP; 03 Jun 2018 20:00:57 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 3 Jun 2018 20:00:57 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 3 Jun 2018 20:00:57 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.87]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.70]) with mapi id 14.03.0319.002; Mon, 4 Jun 2018 11:00:55 +0800 From: "Ni, Ruiyu" To: "Jim.Dailey@dell.com" CC: "Carsey, Jaben" , "felixp@mail.ru" , "edk2-devel@lists.01.org" Thread-Topic: How to Interpret ReadKeyStrokeEX Data Thread-Index: AdP51a/hVUcRd8ZXRbW9WoFUsUlqeAB2jMWg Date: Mon, 4 Jun 2018 03:00:54 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BD232B9@SHSMSX104.ccr.corp.intel.com> References: <3e835c29938d49ea8d285385429870ad@ausx13mps339.AMER.DELL.COM> In-Reply-To: <3e835c29938d49ea8d285385429870ad@ausx13mps339.AMER.DELL.COM> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] 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 03:00:59 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks/Ray > -----Original Message----- > From: Jim.Dailey@dell.com > Sent: Saturday, June 2, 2018 2:27 AM > To: Ni, Ruiyu > Cc: Carsey, Jaben ; felixp@mail.ru; edk2- > devel@lists.01.org > Subject: How to Interpret ReadKeyStrokeEX Data >=20 > (Subject changed) >=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 retu= rns Scan Code and Unicode Character. The above statement only says that consumer should only care one of the fields: Scan Code and Unicode Characte= r. >=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 > 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" i= s pressed, what Unicode Character should be returned since there is no place to return the shift state for SimpleTextIn. I think it should return "#". >=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 > 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 > 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 > 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 > 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 > Regards, > Jim >=20 > > -----Original Message----- > > From: Ni, Ruiyu [mailto:ruiyu.ni@intel.com] > > 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 r= ead > console > > > > 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. > > > > [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 > read > >> console > >> > >> Ray, > >> > >> The patch in the message below was applied to the tree on 12 Feb this > year > >> (5563281fa2b31093a1cbd415553b9264c5136e89). > >> > >> Part of the change to MainTextEditor.c causes an issue where I cannot > enter (at > >> least some) shifted punctuation. For example, after this check in I c= annot > edit a > >> shell script and create a comment because I cannot enter the "#" > character. > >> When I try to type "#", the status bar simply shows "Unknown Command". > >> > >> I don't really understand the change, but if in the MainEditorKeyInput > function in > >> file MainTextEditor.c I delete the "NoShiftState" check from the first= "else > if" > >> below: > >> > >> + // > >> + // 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= _NULL) > || > >> ((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; > >> + } > >> > >> then I am able to enter "#" and other characters that I previously was > unable to > >> enter. > >> > >> Can you have a look at this? I assume any shell binary built with thi= s > change will > >> have a similar issue. > >> > >> Thanks, > >> Jim > >> > >>> -----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 rea= d > console > >>> > >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D682 > >>> > >>> Edit and HexEdit commands assume that SimpleTxtIn translates > >>> Ctrl+ key combinations into Unicode control characters > >>> (0x1-0x1A). > >>> > >>> 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 > combinations. > >>> > >>> The patch changes edit and hexedit to only consumes SimpleTextInEx. > >>> > >>> 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(-) > >>> > >>> ---------8<----- clip ----->8-------- > >>> > >>> -- > >>> 2.16.1.windows.1 > >>> > >>> _______________________________________________ > >>> edk2-devel mailing list > >>> edk2-devel@lists.01.org > >>> https://lists.01.org/mailman/listinfo/edk2-devel