From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::232; helo=mail-it0-x232.google.com; envelope-from=heyi.guo@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D5477220F3C2A for ; Thu, 23 Nov 2017 23:18:05 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id y71so794273ita.1 for ; Thu, 23 Nov 2017 23:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=MTzy+vXSPOlFvmlIijTp3hVxgF8bKCieciUoUOv2mH4=; b=G/6A3Y/CBAdsZZ9GEOoSw2kkjODZa1uE5vZSUTmTiK3Jc+YVCxf2t0MLIPC8ARBWW1 smUlYrIIfRuz53xcP7dMEtd777Go9IOBJkuTgYZ0VngDaHqTZFr7hV87Yi0tW7p6jx8A rWnOFjjR8+PcX+xJTmev8Z2UzA2sWSfNdQniI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=MTzy+vXSPOlFvmlIijTp3hVxgF8bKCieciUoUOv2mH4=; b=J+YASGkSXLKJ80cTsTPPF2HNAhrqaPqyzpEtaQcWzuXRq7BhEi89/UpdrBw/4T1JWr 6099QZMegF4O4tZZJ4PRcMQuR8hH7IepheZbutEBQQVB0qFsU7YhKS2vakNgnF7Xx4GW zAMcv71dnY16siy5aE2MI8TWUOwTY0gZIfbP47QrmJz1dXInOGOpy6hsRGKcdR0e3C4c chEYf8UZnbfwaDoRWt7J2QqMaBM8hmnW76zF6wwwZxmg2MD5GV3XaxNZXw4Y90Z5ud6Z 5iobKcjVeVIwtSBC1oLX1GYUxqpYLvvUlhRGn3clCy0Z2tBd0knkK85n/vQfbKbKNAfg dYjg== X-Gm-Message-State: AJaThX46huHMDQDm7+59+jQQe9LzQEZH51/h9NFCjvb7Bsxc5odLgWWq ftgdZdJL3qavNKPDkmwxEeifTGmoSVg= X-Google-Smtp-Source: AGs4zMZYxtF1JKNSF0V9Nd6wZ+fspHP42wGwUo3wF2QepD3ALZF/+ah09HuK4bmmdz1YjKknsj4XSw== X-Received: by 10.36.40.207 with SMTP id h198mr15824544ith.95.1511508143184; Thu, 23 Nov 2017 23:22:23 -0800 (PST) Received: from [10.33.72.82] ([45.56.152.217]) by smtp.gmail.com with ESMTPSA id o207sm4002628itc.27.2017.11.23.23.22.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2017 23:22:22 -0800 (PST) To: "Brian J. Johnson" , Gerd Hoffmann Cc: "Ni, Ruiyu" , "edk2-devel@lists.01.org" , "Dong, Eric" , "Zeng, Star" References: <1958e840-f0fe-6d8e-44d1-03ff9c9dde7b@linaro.org> <0C09AFA07DD0434D9E2A0C6AEB0483103B9B3162@shsmsx102.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BAB6CB0@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BAB6F41@SHSMSX104.ccr.corp.intel.com> <20171108090713.5hof77t5l3gikpwk@sirius.home.kraxel.org> <7c7d448c-bd00-954a-dcf4-8f83f98f43d6@linaro.org> <6eed14fe-31e7-f0ab-3e80-6fa9847e10e4@hpe.com> From: Heyi Guo Message-ID: <110d99fc-0021-a59b-ad8d-287ef3236356@linaro.org> Date: Fri, 24 Nov 2017 15:21:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6eed14fe-31e7-f0ab-3e80-6fa9847e10e4@hpe.com> Subject: Re: [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 07:18:06 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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)