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

On Wed, May 13, 2026 at 14:24:46 +0000, Alan Mackenzie wrote:
> On Wed, May 13, 2026 at 14:51:03 +1000, Alexis wrote:
> > Ben Knoble <[email protected]> writes:

> > > 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?

> > You are indeed correct. :-) Here's the wiki page about it:

> >   https://wiki.gentoo.org/wiki//etc/portage/patches

> That is not a well written page.  There is no coherent description of
> how one specifies the version(s) of a package a patch should be applied
> to.  Just some cryptic meta-specifications and a few vague examples.

> The text ought to say what ranges of versions can be specified, and how
> to do so.

> The text specifically says "version(s)", so presumably there's some
> syntax for specifying several versions.  But the examples only appear to
> show one specific version each, or any version at all.

I've played around with this feature a little.  It's not really any
better than its documentation.

> I would like to specify versions "6.18.n for n >= 26".  Is this
> possible?  (I suspect not).  If so, how?  If not, what about "6.18.n for
> any n"?

Neither of these is possible.  The three possibilities are (i) no
version information, the patch is applied to all present and future
versions of a package; (ii) a specific version is specified; only that
version gets patched; (iii) a slot identifier is given; all versions in
that slot get patched.

The basic problem seems to be that a directory name is used for this
version info, and you can't put wildcards of any kind into such a name
(at least, not without an unreasonable degree of back-quoting).  If
anybody from the Gentoo portage team is reading, please consider fixing
this problem by providing some better means to specify versions.

For my kernel patch, option (iii) above doesn't gain anything, since in
the kernel packages, the slot is identical to the version number.  So
it's either option (i), which doesn't feel safe, or option (ii) which
feels constricting, since it would need manual intervention on each
kernel release.  This rather negates the purpose of having an automatic
patching mechanism in the first place.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).