Re: Dell Latitude E6400 GRUB patch, Was: [PATCH v1 02/16] manual: improve the description of Canoeboot.

[Leah Rowe]

On 13/05/2025 00:21, Denis 'GNUtoo' Carikli wrote:
> On Mon, 12 May 2025 11:41:26 +0100
> Leah Rowe <info@minifree.org> wrote:
> > My patch forces GRUB to always use set 1. This is the same behaviour
> > used by Linux and SeaBIOS.
> I can see that by reading the patch and your commit message also
> documents what it does quite well.
>
> My guess that GRUB probably has good reasons to do auto-detection here.
>
> Hence the question: is GRUB keyboard handling also broken with the stock
> boot software? What about the distro GRUB ran by SeaBIOS or other
> payloads?

No, it is not broken there, and I alluded to the reason why in my 
previous email, but I'll say again:

If coreboot is operating as a coreboot payload, it tries scancode set 2 
first, otherwise defaults to 1 - and in this case, we have to force it 
to always use 1, for reasons which I explained and which you understand.

However:

When GRUB is operating in BIOS or UEFI mode (i.e. not as a coreboot 
payload), it simply reads the current state and uses that. The factory 
firmware forces scancode set 1.

More specifically:

My patch forces *scancode set 2*, but *with translation*.

In translation mode, scancode set 1 is used. Actual set 1 (not set 2 
with translation) is mainly used on really, really, really, and I mean 
really like, 1980s, PCs.

So the bug still exists, but is not triggered on BIOS/UEFI GRUB. The bug 
is only triggered in the coreboot payload, and this is what I patch.

This is my patch:

https://browse.libreboot.org/lbmk.git/tree/config/grub/default/patches/0009-at_keyboard-coreboot-force-scancodes2-translate.patch?id=6089716f07caf6b4690df1e1c2f2089a27a0b514

Also, this extra patch fixes another bug:

https://browse.libreboot.org/lbmk.git/tree/config/grub/default/patches/0009-at_keyboard-coreboot-force-scancodes2-translate.patch?id=6089716f07caf6b4690df1e1c2f2089a27a0b514

The second patch prevents GRUB from spewing "Unknown character 0xff" 
when the user has a stuck key; without this patch, a stuck key can 
effectively result in a brick, if GRUB is your first payload.

This too was not merged by GRUB. Perhaps I should try submitting these 
again; and perhaps ask Patrick Rudolf to re-submit his xHCI patches.

> If it's also broken in other cases, then it would make sense to fix
> things for all these cases and not just the Coreboot case.
Look at my patch, and you'll see that I specifically use an ifdef, so 
that my code only modifies coreboot behaviour; behaviour on other GRUB 
targets remains the same.
> And if not, it might probably not make any sense for GRUB to carry out
> computer-specific hacks if it can avoid it. In that case if it just
> works with SeaBIOS + GRUB, we probably have the means to get through
> the issue and fix it for real in the right place. But this also
> requires to spend time to do that.

Not computer-specific.

I simply change this behaviour on all computers when GRUB is a coreboot 
payload. It hasn't broken any other machines.

Set 2+translate is pretty much universal. All operating systems and most 
firmwares enable translation. GRUB is just trying to be cute, doing 
something novel that nobody else does, in the most over-engineered GNU 
way possible.

--
Company director, Minifree Ltd
Registered in England, No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK

OpenPGP_0x5C654067D383B1FF.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature