From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:400e:c00::22f; helo=mail-pf0-x22f.google.com; envelope-from=heyi.guo@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 EA90F20355229 for ; Wed, 8 Nov 2017 05:31:15 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id b85so1726358pfj.13 for ; Wed, 08 Nov 2017 05:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=mGdEUZKBl6iNAitvhf0sj+kemwz4w+m5lEnltWgt4aY=; b=ZQQ89KJ80myLdPVdiIrnjfQkfrpdVQ8+vQdqv4IqxgCMFXk+v5siBz1SwD9f5+AMEC N/+42E23RhWpT2pUM40CEooLYaQoz+MkyvTdeGM2zc9hWLMcEzTPE05Yw+/z/MdY0nT3 6oxDhVsSdp8jFAh189smkhFFQdZeXeChHL3dM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=mGdEUZKBl6iNAitvhf0sj+kemwz4w+m5lEnltWgt4aY=; b=SOhLriwx76AQNqP55PodYoFGxDQXWCUQpRcChZ0NugAtqefiVGnw8lULdatUHUUVnn XrUdAY4Fy8UFhcJPusZc4UBCCtml1iEaj0UZ2MCGGfOTsEvGizziZpLH9jxK7G1gGpx8 dwzcsSQoGEXz9N+3rELlXn7R4lTSDm19sE6bercvINSZQzXUbIDmRxL8Ypag5dedKQ8Q 4LZvIihjL9YVtpj+be7vR9xiyzqA7ZijdSGvOAEniA2CKvi3/WaLSzw0BEfuunNj8gZk 77m1tUveJQdrp+pcWVXjxXSNRS/5HDIZB5V6Qql5/MSxhpkem6moehd9NIbHejLlBUrF 7jSg== X-Gm-Message-State: AJaThX5/n+tkG2M67lDCW4zo5c/xWfLIS0rV0cb7p1WC1XtnLW+xDrM/ G5Hius/jjSdRq0BKaxRD3SDEWJLNC4NnlA== X-Google-Smtp-Source: ABhQp+QNQNsUs2y2ttHao4j6xFqBU1VkH5FaJLuuFw8hXJt74C2e69MnTz9JTVux/VH30Q3vLZMgWg== X-Received: by 10.99.110.197 with SMTP id j188mr535157pgc.34.1510148116058; Wed, 08 Nov 2017 05:35:16 -0800 (PST) Received: from [10.83.214.206] ([104.237.90.128]) by smtp.gmail.com with ESMTPSA id t4sm2423595pgp.49.2017.11.08.05.34.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 05:35:15 -0800 (PST) To: Gerd Hoffmann 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> Cc: "Ni, Ruiyu" , "Zeng, Star" , "edk2-devel@lists.01.org" , "Dong, Eric" From: Heyi Guo Message-ID: <7c7d448c-bd00-954a-dcf4-8f83f98f43d6@linaro.org> Date: Wed, 8 Nov 2017 21:34:33 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <20171108090713.5hof77t5l3gikpwk@sirius.home.kraxel.org> 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: Wed, 08 Nov 2017 13:31:16 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 :) Thanks, Heyi > > HTH, > Gerd >