[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] at_keyboard: fix unreliable key presses
From: |
Daniel Kiper |
Subject: |
Re: [PATCH] at_keyboard: fix unreliable key presses |
Date: |
Tue, 15 Oct 2019 13:54:15 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Wed, Oct 02, 2019 at 11:48:10PM +0200, Michael Bideau wrote:
> This patch fixes an issue that prevented the 'at_keyboard' module to work
> (for me).
>
> The cause is a bad/wrong return value in the function
> 'grub_at_keyboard_getkey()' in file 'grub-core/term/at_keyboard.c' at line
> 237.
>
> My symptoms were to have an unresponsive keyboard: keys needed to be pressed
> 10x and more to
> effectively be printed, sometimes generating multiple key presses (after 1 or
> 2 sec of no printing).
> Very problematic for typing passphrase in early stage (with
> GRUB_ENABLE_CRYPTODISK).
> When switching to 'console' terminal input, keyboard works perfectly.
> It also worked great with grub 2.02 packaged by Debian (2.02+dfsg1-20).
> It was not an output issue, but an input one.
>
> I've managed to analyse the issue and found where it came from: the following
> commit:
> ///////// commit /////////
> Commit: 216950a4eea1a1ead1c28eaca94e34ea2ef2ad19
> Author: Vladimir Serbinenko <address@hidden>
> Date: Mon May 8 21:41:22 2017 +0200
>
> at_keyboard: Split protocol from controller code.
>
> On vexpress controller is different but protocol is the same, so reuse the
> code.
> ///////// end of commit /////////
>
> 3 lines where moved from the function 'fetch_key()' in file
> 'grub-core/term/at_keyboard.c', to the begining of function
> 'grub_at_keyboard_getkey()' (same file).
> But returning '-1' made sense when in function 'fetch_key()' but not anymore
> in function 'grub_at_keyboard_getkey()', which should return
> 'GRUB_TERM_NO_KEY'.
>
> I think it was just an incomplete cut-paste, missing a small manual
> correction.
> Better fix it.
Missing SOB. I can add it in behalf of you if it is not a problem
for you. And I will tweak a commit message a bit before committing.
Otherwise Reviewed-by: Daniel Kiper <address@hidden>
Daniel