DRM/KMS: countdown started

[tlaronde%polynum.com@localhost]

I have received today, sent by Martin Husemann (thanks!), a copy of the
trees: cvs, git and hg.

So the countdown is started. I give me at most 3 months to disentangle
the tree in order for the present Linux originated DRM/KMS
implementation to be clearly severed so that alien and awkward
interfaces do not creep in the NetBSD kernel and so that, eventually,
graphics capabilities can be tested and opt in later in the process,
without taking down the whole kernel in case of problem.

Severing will be the first thing done. Whether I will be able, in this
first stage, to allow, from this newly created branch, to still
optionally use the current implementation of DRM/KMS is an open
question, and this goal is beyond the objectives of the first stage.


You will hear from me, reporting success or failure, at the latest on
14th of October 2023.

Le Thu, Jul 06, 2023 at 01:32:31PM +0200, tlaronde%polynum.com@localhost a écrit :
> As I think I have proven with inetd(8), when I engage to do something, I
> do.
> 
> I have started, some months ago now, to review problems with the display
> starting by the end: the monitor.
> 
> I have updated the DMT (sys/dev/videomode) and identified some problems
> (with Mac monitors) and published the result (that NetBSD has ignored
> while this corrects things, breaks nothing and is at least a step
> forward, independent from anything else).
> 
> So now I plan to resume my walk through the code but what is on
> https://wiki.netbsd.org/releng/netbsd-10/ seems to just confirm my
> engineeging guts feeling: that DRM/KMS is too big, too convoluted, too
> alien and that it's a lost battle to try to make this work with the
> kernel.
> 
> I'm the "software Hercules".
> 
> I have already "cleaned the GRASS stables"---because the GPL GRASS
> state was not satisfactory, so I simply came back to the last public
> domain CERL GRASS release and was able, alone, to get everything
> working---and to my surprise not only have what GPL GRASS had working,
> but also what GPL GRASS had _not_ working, while I had simply reorganised
> and posixified the sources: I had added nothing back then (now it is
> my professional code base; it has of course evolved and saw many
> additions).
> 
> I have also "cleaned the TeX stables"---once again totally unsatisfied
> of having the obligation to download gigabytes of stuff for a software
> system written to be ultra-portable (this is string manipulation so this
> is typically almost totally userland stuff) and small, a needle lost in
> tons of hay stack. The result is kerTeX. And not only a whole
> distribution, but I have written an extension: Prote, to accommodate
> LaTeX new requirements.
> 
> So yes: this is a perfectly valid engineering solution, if you took the
> wrong way to go back to the fork, and take another one.
> 
> So I'm proposing to go back to the fork (for this part starting by
> identifying what is immune, orthogonal to the thing) when the Linux
> DRM way was taken and to eject the Linux DRM/KMS.
> 
> If DRM has to be addressed, it will be addressed after, but doing it
> our own way.
> 
> And I'm proposing to help.
> -- 
>         Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
>                      http://www.kergis.com/
>                     http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C