From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Zlqbf-0005J4-SB for mharc-grub-devel@gnu.org; Mon, 12 Oct 2015 23:50:31 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlqbb-0005If-5D for grub-devel@gnu.org; Mon, 12 Oct 2015 23:50:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlqbX-0002kK-PM for grub-devel@gnu.org; Mon, 12 Oct 2015 23:50:26 -0400 Received: from mail-lb0-x234.google.com ([2a00:1450:4010:c04::234]:34544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlqbX-0002kA-Ir for grub-devel@gnu.org; Mon, 12 Oct 2015 23:50:23 -0400 Received: by lbbck17 with SMTP id ck17so5145574lbb.1 for ; Mon, 12 Oct 2015 20:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=urkMphmAGYSC9GsaxNnJZlE/s0xa1pfG6MGnTr8QPd4=; b=un3VW1tidD9vqnui53MfPufD9/ODEUedWPW9rQMrKpSv7AobaDHphg1G5a0KdRFutU RRwfqpg8bKFdrCL1lts7yO8dDUIMAmcbPDbX2PrDRms59IyNv+OmsRCFVRDf0kaVwZ8G AX5ZQqOY8JN4IaTq+w+tfHkT9qyZdisnhywCEKq6/rlP5rZxmScM1FMyvZ7+HNbYB/4X LyQFMtXyNJ6ekbGOs2stqDJ4Fc29/3d0hZ8vxAd45PjpFQv4BYgSbT85xdPrRn/6fbrR 6sAtWDsdS7A6KwbFG9CrlzkxN2y2TDxDUC7YS03u6EFiSGN/b+KvcXJSUyXyD2QpKvEX Fa/A== X-Received: by 10.112.158.1 with SMTP id wq1mr13613707lbb.67.1444708222633; Mon, 12 Oct 2015 20:50:22 -0700 (PDT) Received: from [192.168.1.43] (ppp91-76-142-206.pppoe.mtu-net.ru. [91.76.142.206]) by smtp.gmail.com with ESMTPSA id jo4sm145168lbc.11.2015.10.12.20.50.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 20:50:21 -0700 (PDT) Subject: Re: [PATCH] Make CTRL and ALT keys work as expected on EFI systems (version 5). To: grub-devel@gnu.org References: <1393366348-22020-1-git-send-email-pjones@redhat.com> <56195D9A.2010306@gmail.com> <20151012144727.GB19125@redhat.com> From: Andrei Borzenkov Message-ID: <561C7F7C.7090708@gmail.com> Date: Tue, 13 Oct 2015 06:50:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151012144727.GB19125@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::234 Cc: edk2-devel-01 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 03:50:30 -0000 12.10.2015 17:47, Peter Jones пишет: > On Sat, Oct 10, 2015 at 09:48:58PM +0300, Andrei Borzenkov wrote: > > Sorry - realized I should have addressed your question and said one more > thing. > >> Are there open issues with this patch? Is it used by Fedora? The part about >> SHIFT state bothers me, what happens for non-ASCII printable characters? >> UEFI spec is extremely vague here. > > As for non-ASCII printables, I have no idea. I literally couldn't find > a keyboard that generated any around my office. Even my European and > Japanese coworkers don't seem to have them. That said, given the May be we should ignore SHIFT bit for any key event that has valid UNICODE character. At least that seems to be what UEFI spec intends to say. Code in EDK2 does it only for letters (characters affected by Caps Lock) but I do not see how program can usefully interpret SHIFT modifier on something like `5' or `/'. Adding EDK2 to Cc. > comment here: > https://github.com/vathpela/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c#L481 > and the two tables here: > https://github.com/vathpela/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c#L36 > https://github.com/vathpela/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c#L149 > my guess is that on the vast majority of systems they just don't produce > any keypress. We could do things like make right-alt act like AltGr and > synthesize them ourselves, of course, if there's a significant need. > (Awesomely, AltGr is defined by the EFI modifier list but not mapped > from the USB bits. Which probably doesn't matter, since nobody uses > keyboards with AltGr keys.) > >> As currently there is no way to actually input Ctrl-X or similar this is >> needed. It may also allow us to actually implement keystatus on EFI. > > One issue related to implementing keystatus is the "Windows Fast Boot" > feature, enabled by default in nearly all "client" machines now. (It's > a Windows logo requirement.) This feature basically says not to probe > USB and the like by default. So on any machines where your input > device is USB, what winds up happening is that it probes for HII devices > when you call ->read_key_stroke() or ->read_key_stroke_ex() the first > time. Depending on the hardware configuration, how many devices are > plugged in, how many hubs away the keyboard is, etc., this can take a > surprisingly long period of time. (FWIW, I *think* > register_key_notify() and set_key_state() will also trigger the driver > loading and probing on most implementations.) > But that should be OK. keystatus would set EXPOSE and call read_key_stroke_ex which would kick off USB scan. Or so I understand. > For practical purposes right now, this is pretty much okay with how most > people are using GRUB. But if somebody wanted to implement "don't show > menus unless the user requested it before the reboot, or the last boot > failed" in their grub config file, then the user gets a much quicker > boot experience if we don't scan the keyboard. >