On 11/24/2017 01:21 AM, Heyi Guo wrote:
Hi Brian,
在 11/9/2017 12:00 AM, Brian J. Johnson 写道:
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.
Can we really use a PCD in TerminalDxe? I remember some experts in the
community said that TerminalDxe is a pure UEFI driver; it can't use PCD
since PCD is not defined in UEFI spec.
Thanks,
Gary (Heyi Guo)
Gary,
I'm not sure what the rules are for PCDs. I'm just saying that if
there's a good way to make the delay configurable for each platform, I
wouldn't be against it. 2 seconds is a long time in some contexts.
--
Brian J. Johnson
Enterprise X86 Lab
Hewlett Packard Enterprise
brian.john...@hpe.com
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
