drivers/mouse: Tolerate initial pointer jitter

[gouveags]

Incidental pointer movement can cancel autoboot and leave an unattended machine at the menu. Allow initial movement within one terminal cell of the pointer's starting position on both axes before activating the pointer and reporting a movement event.

The pointer stays hidden until displacement reaches one cell on either axis, or a mouse button or the scroll wheel is used. Small movements accumulate, so slow deliberate movement still activates it. Once activated, normal mouse behaviour applies.

The change adds 10 lines to common/drivers/mouse.c. Existing input waits and countdown timers are unchanged.

Validation:

• LLVM BIOS, IA32 UEFI, and x86-64 UEFI builds pass with warnings treated as errors.
• 50 QEMU checks pass across SeaBIOS and OVMF relative/absolute pointers, covering jitter, deliberate movement, buttons, keyboard selection, clicks, configuration controls, the editor, and failed-boot recovery.
• GCC ASan/UBSan tests cover all 261,121 fixed-point positions inside the dead zone and boundary activation. An exact-source UEFI input test passes with GCC sanitizers and optimised Clang, verifying one timer across 64 jitter events and the 250 ms interval. Unchanged upstream fails the intended jitter assertion.

No physical hardware test has been performed. UEFI wheel handling is tested through simulated firmware input services; physical firmware wheel delivery is not covered. AI assistance is disclosed in the commit trailer.

Fixes #689.

[iczelia]

No. This is not what I meant by "soft decision boundary." Rather, I meant that the cursor can move around for a bit before cancelling shutdown. For what it does, this pull request is extremely overengineered; it could have been a single line of code (or so) had a human written it.

[gouveags]

@iczelia Thanks for the (not so) constructive feedback! The PR was created as a draft because I intended to review it. It was also made for alignment purposes, so you could give me some feedback on the direction, as I wasn't even sure what "soft decision boundary" meant, especially in a codebase I had never worked on before.

I'd still like to contribute if you're willing to help me with this one. I'll make mistakes, but I'm willing to learn and improve :D

[gouveags]

I'll make some changes and propose a new solution in a bit.

[iczelia]

@gouveags If you wanted to accomplish what you just did, you could have also reverted this commit: 134b7a2.

You have to understand the asymmetry here: it's easy to prompt a LLM to submit a pull request, it's hard and time consuming to review it. I am personally somewhat biased against LLM generated contributions, because in that case I would prefer to prompt the model myself and fix its mistakes without a proxy.

Without large language models, you would have spent more time around the codebase and have been able to come up with a better solution (such as reverting the commit above, or the few-line patch I was just talking about).

[gouveags]

@iczelia I get your point, and thanks for really taking the time. Still, the PR was there for me to review. I explicitly asked for it to be a draft so I could spend some time getting to know the codebase better when I had the chance before making it ready.

Thanks anyway! I love C codebases, and I'll definitely dive deeper and get more acquainted with Limine.

[Heisen47]

I faced a similar issue with my mouse / trackpad not working after updating omarchy . Are you working on this?

[iczelia]

Excellent. This is much better. I will have a look tomorrow.

[gouveags]

@iczelia thanks very much! This one took me a lot of time to get right. Let me know what you think!