Hi Javier and Renaud,
Sorry for late reply but I am busy with other important stuff.
I will try to take a look at the patch next week.
Daniel
On Tue, Jan 19, 2021 at 09:07:30AM +0100, Javier Martinez Canillas wrote:
> 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
