if (! KEYBOARD_ISREADY (grub_inb (KEYBOARD_REG_STATUS))) - return -1; + return GRUB_TERM_NO_KEY; at_key = grub_inb (KEYBOARD_REG_DATA); old_led = ps2_state.led_status; ///////// end of patch /////////
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'.