Re: Soft scrolling on framebuffer consoles - with GPM Handling - revised for kernel 6.18.28 (etc.)

On 2026-05-15, Alan Mackenzie wrote:

> Hello, Ben.
>
> On Wed, May 13, 2026 at 08:31:31 -0400, Ben Knoble wrote:
>> Hi Alan,
>
>> > Le 13 mai 2026 à 07:47, Alan Mackenzie <[email protected]> a écrit :
>> > On Tue, May 12, 2026 at 20:24:15 -0400, Ben Knoble wrote:
>
> [ .... ]
>
>> >> However, using /etc/portage/patches (or w/e the path is; on mobile) it
>> >> should be possible to make use of the patch somewhat easy?
>
>> > Thanks for the idea!  I've used /etc/portage/patches before for a couple
>> > of personal enhancements.
>
>> > Thanks for the link to the pertinent wiki page, Alexis.  It was useful.
>
>> > The patch should pretty much work as it is in /etc/portage/patches.  I
>> > just need to work out precisely how to say "apply to version 6.18.26
>> > onwards" in the patch file path.  I was wondering how to specify the
>> > option -p1 to patch (that's the option which ignores the first component
>> > of the file paths when searching for source files to amend), but it seems
>> > this is the default anyway.
>
>> > The only problem I see is that when the kernel's console code gets
>> > further enhanced and the patch no longer applies, it could take me some
>> > while (possibly two or three days) to update the patch.  This would be
>> > inconvenient (kernel builds failing) for those with the patch already in
>> > /etc/portage/patches.
>
>> That is indeed a concern; see
>> https://github.com/gentoo/gentoo/pull/46238 where I had to rebase a
>> Gentoo-carried patch for Git. I imagine you’d do something similar.
>
>> > So I'll take a closer look at this.  Hopefully it will be as simple as
>> > asking people to do
>
>> >    # mv .../6.18.28-GPM-NO-MD.20260511.diff /etc/portage/patches/...
>
> It seems there is no finer granularity in the /etc/portage/patches/
> mechanism than "apply to all versions" or "apply to this particular
> version".  The latter doesn't make much sense, since if you have to make
> a new directory each time there's a new kernel, you might as well just
> apply the patch by hand.

I think this still has the added benefit that application is
automatically handled by portage.

Two things occur to me:

- When adding a new version for which you want to use it without
  modifications, can symbolic links be used? (so the new directory would
  be a link to the old one)

- Having per-version directories might make e.g. sharing this in a VCS
  repository more suitable, so you'd have in the repository directories
  corresponding to the tested kernel versions. But whether this is
  sensible or not will depend on how often there are kernel updates and
  on whether you'd just include (in the gentoo sense) stable kernels or
  also non-stable ones. Could range between useful to unusable (say, if
  you have to constantly rename or add directories).


> So I think the best available is:
>
> # mkdir -p /etc/portage/patches/sys-kernel/gentoo-sources
> # mv .../6.18.28-GPM-NO-MD.20260511.diff \
>  /etc/portage/patches/sys-kernel/gentoo-sources/
>
> ..  As already mentioned, this will carry on working until it doesn't, at
> which point it will block the merging of further kernels until amended.
>
> When I post the next amended version of the patch, I will amend the
> instructions for using it.
>
>> Best of luck. Glad I could help!
>
> Thanks!

-- 
Nuno Silva