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 <rmetrich@redhat.com>
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