public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Brian J. Johnson" <brian.johnson@hpe.com>
To: Heyi Guo <heyi.guo@linaro.org>, Gerd Hoffmann <kraxel@redhat.com>
Cc: "Ni, Ruiyu" <ruiyu.ni@intel.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"Dong, Eric" <eric.dong@intel.com>,
	"Zeng, Star" <star.zeng@intel.com>
Subject: Re: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?
Date: Wed, 8 Nov 2017 10:00:52 -0600	[thread overview]
Message-ID: <6eed14fe-31e7-f0ab-3e80-6fa9847e10e4@hpe.com> (raw)
In-Reply-To: <7c7d448c-bd00-954a-dcf4-8f83f98f43d6@linaro.org>

On 11/08/2017 07:34 AM, Heyi Guo wrote:
> 
> 
> On 11/08/2017 05:07 PM, Gerd Hoffmann wrote:
>> On Wed, Nov 08, 2017 at 04:44:37PM +0800, Heyi Guo wrote:
>>>
>>> 在 11/8/2017 4:34 PM, Ni, Ruiyu 写道:
>>>> No.
>>>> Even a terminal tool can recognize F10, it still needs to translate 
>>>> it into "ESC [ V"
>>>> and send the three bytes to firmware.
>>> Got it. But the 2 seconds timeout is not for this situation, right? If
>>> terminal tool could translate and send the key sequence, I think it can
>>> complete 3 bytes transfer in a very short time, isn't it? E.g. 9600 
>>> baud / 8
>>> = 1200 Bytes/s (ignore control bits).
>>>
>>> So 2 seconds timeout is still for user to enter the sequence "ESC [ V"
>>> manually?
>> No.  Alot of software has this kind of delay because it is recommended
>> in some classic unix documentation to avoid mis-interpreting incomplete
>> terminal control sequences coming from slow terminals.
>>
>> Where a "slow terminal" which actually would need such a long delay is a
>> physical terminal from the 70ies of the last century, or a virtual
>> terminal hooked up over a *really* slow network connection.
>>
>> Reducing the delay from 2 seconds to roughly 0.2 seconds should be
>> pretty safe, things are not that slow any more these days :)
> That will be great if we can make such change :)
> 

You'd be surprised how much delay you can get with a few layers of 
firewalls, VPNs, and cross-country (or intercontinental) WAN links. 
That's the advantage of serial:  you can tunnel it anywhere.

Here's a quick workaround:  if you start typing other text after the 
ESC, the terminal driver will see the new keystrokes and resolve the ESC 
immediately, without the delay.  For instance, at the shell prompt, type 
something, press ESC to clear the line, then just start typing new text 
without waiting for the timeout.  The line will be cleared and the new 
text will appear correctly, without delay.

On setup screens, I usually hit escape to return to the previous screen, 
then hit one of the arrow keys to cause the ESC to be processed without 
the timeout.  That works pretty well in practice.

I'd think a PCD to control this delay would be appropriate, though.
-- 
Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise



  reply	other threads:[~2017-11-08 15:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-08  7:04 [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed? Heyi Guo
2017-11-08  7:24 ` Zeng, Star
2017-11-08  7:55   ` Ni, Ruiyu
2017-11-08  8:30     ` Heyi Guo
2017-11-08  8:34       ` Ni, Ruiyu
2017-11-08  8:44         ` Heyi Guo
2017-11-08  8:46           ` Ni, Ruiyu
2017-11-08  8:51             ` Heyi Guo
2017-11-08  9:07           ` Gerd Hoffmann
2017-11-08 13:34             ` Heyi Guo
2017-11-08 16:00               ` Brian J. Johnson [this message]
2017-11-24  7:21                 ` Heyi Guo
2017-11-28 17:55                   ` Brian J. Johnson
2017-11-29  4:18                     ` Andrew Fish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6eed14fe-31e7-f0ab-3e80-6fa9847e10e4@hpe.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox