From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.93; helo=mga11.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 C858C211211F7 for ; Wed, 5 Sep 2018 22:26:34 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Sep 2018 22:26:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,334,1531810800"; d="scan'208";a="86426360" Received: from ray-dev.ccr.corp.intel.com (HELO [10.239.9.8]) ([10.239.9.8]) by fmsmga004.fm.intel.com with ESMTP; 05 Sep 2018 22:26:32 -0700 To: Heinrich Schuchardt Cc: Leif Lindholm , Alexander Graf , Takahiro Akashi , Rob Clark , U-Boot Mailing List , edk2-devel@lists.01.org References: <43d78bc7-75d8-3133-d63c-18658c65bce1@gmx.de> From: "Ni, Ruiyu" Message-ID: Date: Thu, 6 Sep 2018 13:27:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <43d78bc7-75d8-3133-d63c-18658c65bce1@gmx.de> Subject: Re: Implementing EFI_SIMPLE_TEXT_INPUT_PROTOCOL X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 05:26:35 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 9/6/2018 11:27 AM, Heinrich Schuchardt wrote: > Hello Ruiyu, > > currently I am struggling a bit with interpreting the UEFI spec > concerning the EFI_SIMPLE_TEXT_INPUT_PROTOCOL. > > In UEFI spec 2.7. chapter 12.1.2 ConsoleIn Definition there is this > sentence: > > "Only the control characters defined in Table 100 have meaning in the > Unicode input or output streams." > > Table 100: > > U+0000 Null character ignored when received. > U+0008 Backspace. Moves cursor left one column. > U+0009 Tab. > U+000A Linefeed. Moves cursor to the next line. > U+000D Carriage Return. Moves cursor to left margin of the current line. > > Rob interpreted this in a patch for U-Boot such that he simply > suppressed all other Unicode characters in the 0x00-01F range except for > special treatment of 0x001b as ESC. > > When I look at EDK2 function USBKeyboardReadKeyStroke() > (MdeModulePkg/Bus/Usb/UsbKbDxe/EfiKey.c:700) it seems that EDK2 would > pass CTRL+C as Unicode character U+0003 (cf. your patch 608817ad7114 > "Change the SimpleTextInEx implementation to return CTRL+C"). > > The same seems to be the case in function KeyboardReadKeyStroke() > (MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KbdTextIn.c:265). > > So do I get it right that for CTRL+A to CTRL+Z we should return a value > U+0001 - U+001a in Key->UnicodeChar and table 100 is about meaning of > control characters only and does *not* prescribe a filter? The reason to return U+0003 for CTRL+C because SimpleTextIn cannot return the CTRL state so it uses U+0003 to tell caller that CTRL+C is pressed. I think your interpretation to the spec is right. > > But what about CTRL+[ - CTRL+_ ? Why are they suppressed in the EDK2 > keyboard drivers? How do we enter U+001c - U+001f? Good question. I didn't think about how to translate CTRL+[ and etc. The patch I made 7 years ago was to meet the purpose how to tell caller the CTRL+[ALPHA] is pressed. There was no requirement to tell caller whether CTRL+[ (etc.) is pressed at that moment. I think since SimpleTextInEx is introduced in UEFI Spec, which can return more precise key state/toggle information, caller should use the Ex version. I think it's ok for your driver to translate CTRL+[. I doubt any consumer code cares about that. > > Best regards > > Heinrich > -- Thanks, Ray