Hello, It appears that the proposal works fine on all systems I could test except one: a HP DL380p Gen 8. On that system, querying the set fails: the ACK bytes in write_mode(0) work perfectly, but then 0xFE ("NACK") is read, as if the keyboard didn't want to send back the set in use. Hence, query_mode() returns 0, causing set1 to be used, but unfortunately the system expects set2 to be used. I tried using the "resend" command, but nothing helps. I'm hence proposing a fallback solution for this kind of hardware where the admin can add a "at_keyboard_fallback_set" environment variable in grub.cfg that would end using a specific set if query_mode() fails. See proposed patch in attachment. Renaud. On 12/14/20 5:47 PM, Renaud Métrich wrote: > Hi Vladimir, > > Thanks for the hint, this was obvious now. > > Please find attached the new patch which definitely fixes the issue. > > It has been tested on various hardware (see git commit details). > > In a nutshell the solution is to stick to set 1 if controller is in > Translate mode, and use set X otherwise, X being the queried mode. > > Additionally, in controller_fini, nothing has to be restored, since > nothing was changed. This fixes an issue when switching between > at_keyboard, console, and at_keyboard again, in case queried set is > not the actual used set. > > Renaud. > > On 12/11/20 3:08 PM, Vladimir 'phcoder' Serbinenko wrote: >> On Fri, Dec 4, 2020 at 5:53 AM Renaud Métrich >> wrote: >>> Hi, >>> >>> Testing the proposed patch on my old Asus N53SN in Legacy failed: as >>> soon as at_keyboard is selected, the keys are corrupted and it's >>> impossible to do anything. >>> >>> Digging into this, it appears that query_mode() returns 2 (so set2 >>> needs to be used), but in fact internally the keycode are the ones >>> expected by set1. >> This is because the patch doesn't take into account that controller is >> in "translate" mode. >> @Javier Martinez Canillas : Can you make your patch check whether >> KEYBOARD_AT_TRANSLATE is set ? >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel