DRM/KMS

[tlaronde%polynum.com@localhost]

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