Big picture I think the goal is to not make the driver depend on the PCD protocol. A fixed at build PCD is just part of the build system, so not an issue.
Thanks, Andrew Fish > On Nov 28, 2017, at 9:55 AM, Brian J. Johnson <brian.john...@hpe.com> wrote: > > 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 <mailto:brian.john...@hpe.com> > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
