Hello Vladimir and Daniel,
Could you please let us know your thoughts on Renaud's investigation
and patches? Thanks a lot for your help.
On 1/8/21 3:00 PM, Renaud Métrich wrote:
> 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.
>>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
