Re: [PATCH] at_keyboard: Fix keyboards that report IBM PC AT scan codes

[Javier Martinez Canillas]

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