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.31; helo=mail-in21.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.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 BD06B20974100 for ; Mon, 4 Jun 2018 07:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528123800; x=2392037400; 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=Wcxxo6OFDBE+xd/sehVc/SjnOZPcwjWKsN9UjSmox+A=; b=LhZKYKOCNCjbfCNV2uaqz8idKi5PmBpKvPoYglwerC+XlyaKK9Iyasnik4ohIC1U jTqE4qcBFT41uvq5c3YwP9TBGOXypRTxsib1ZccM4EuMa42BIzK09T5T+OfT3Qhj BNTMJPqYm0XZvRPqLTa47YO3xjE1zf6+q9it/ZGxoVslWR4dfW1ExuQSSewLtwxc UKPR6pYCjjzEufrb97akqHnhIQvoS1VFg/kF1wm51TNO/dfgEiGjoWVfovs07bfO 22pdc5qUj5eZGmmXBxtggkosrFtN7/nW3e3WbGRPFBNoiagbtfZ9ueCejQm8pVwk SieQIFSZaM9BVDKTiRY9+w==; X-AuditID: 11ab0215-217ff70000002a18-f9-5b155198bea0 Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 9E.72.10776.891551B5; Mon, 4 Jun 2018 07:50:00 -0700 (PDT) MIME-version: 1.0 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9S00AXZZVCP410@mr2-mtap-s03.rno.apple.com>; Mon, 04 Jun 2018 07:50:00 -0700 (PDT) Received: from [17.234.22.162] (unknown [17.234.22.162]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9S00JW8ZV85N10@nwk-mmpp-sz10.apple.com>; Mon, 04 Jun 2018 07:50:00 -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: a7c7e4cf-3b1f-4425-81c9-2c9a9853f8ec 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: 74a91f14-4b0a-4354-8368-4f48a5182f48 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-04_11:,, signatures=0 Sender: afish@apple.com From: Andrew Fish In-reply-to: <5108c0244ffb45ccb0208dd0a1ed2beb@ausx13mps339.AMER.DELL.COM> Date: Mon, 04 Jun 2018 07:49:54 -0700 Cc: ruiyu.ni@intel.com, jaben.carsey@intel.com, edk2-devel@lists.01.org, felixp@mail.ru Message-id: <51978119-FF46-425A-A7E9-8C1EBD3C7B1E@apple.com> References: <3e835c29938d49ea8d285385429870ad@ausx13mps339.AMER.DELL.COM> <734D49CCEBEEF84792F5B80ED585239D5BD232B9@SHSMSX104.ccr.corp.intel.com> <5108c0244ffb45ccb0208dd0a1ed2beb@ausx13mps339.AMER.DELL.COM> To: Jim.Dailey@dell.com X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUiuPlRu+6MQNFog4mTdS32HDrKbDHpwQF2 i41Nf1gtJn2stHjZs5rdgdVj0swZzB6L97xk8uie/Y/FY8rcI6wBLFFcNimpOZllqUX6dglc GQeOvmAtOCFT0T1jL1MD4xGxLkZODgkBE4ldP3YydjFycQgJHGSS+HNxBxtIgldAUOLH5Hss XYwcHMwC8hIHz8uChJkFtCS+P2plgahfzyTxYN5GZghnIpPEhwfL2SCmskv8+bWDBcLWltiw 4RycPafzMiuM/XDzW6h6LokFW09DxXUlnvz/DGWzSaw/sYQJwtaSWDPtCTuMvXPdUzYYe1// Hqg4p8T5LxPZQY6WENCRmH/cHyKcLbGv9w4ziC0sIC7x7swmKNtS4vZLiJFsAsoSK+Z/ALM5 BbwkXh7cD3YCi4CqxK4lJ9ghno+U6Fu1ngUSPjYSd451gp0gJHCZUWLDmmwQWwRo/u4zL6HO UZL4v+sI8wRGuVlIQToLEaSzkIJ0ASPzKkbh3MTMHN3MPCNDvcSCgpxUveT83E2MoISwmkl0 B+P8V4aHGAU4GJV4eDWsRKOFWBPLiitzDzFKc7AoifMuDuKIFhJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cBo+XWDnEOVt8dvrzbdbYs6uDSND7BbOZx04lD9MjNmE8e2xy96Yi/Uz0t49umB 4LpdjzLE3IJK43UWM91QuXdHpaJG592D/ceXbHlibiajcdhNj93wslm+4vxr0ku6BEXfrdn+ 7FiT6oStvSKtrEG1t9i0XqpsN33jGhrMK3+E56rM9HjZVVFKLMUZiYZazEXFiQBX4xDF6QIA AA== 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:50:02 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Jim, The big picture difference is the original SimpleTextIn was the least common denominator with a serial terminal. The Ex version added more info about keyboards, so richer info on modifier keys. Thanks, Andrew Fish > On Jun 4, 2018, at 7:46 AM, Jim.Dailey@dell.com wrote: > > >> Thanks/Ray >> >>> From: Jim.Dailey@dell.com >>> >>> 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. >> Considering there is the other protocol called SimpleTextIn which only returns >> Scan Code and Unicode Character. The above statement only says that >> consumer should only care one of the fields: Scan Code and Unicode Character. > > 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): >>> >>> 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 = 0 > Unicode Char = 0x0023 ("#") > Shift Information = 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 "#" (without >>>> 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. > > As far as I can tell I am using the standard MdeModulePkg USB driver. > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel