Le Fri, Jul 07, 2023 at 01:05:03AM +0900, PHO a écrit :
> On 7/6/23 20:32, tlaro...@polynum.com wrote:
> > 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.
>
> Wait, are you suggesting we should throw the Linux DRM/KMS away and build
> our framework and individual drivers?
>
> Hmm... hmmmm...
>
> I agree that it's a huge convoluted alien that is ridiculously hard to tame.
> I'm currently trying hard to make the half-ported vmwgfx driver work on
> NetBSD. In my local tree it now compiles and successfully initializes but
> fails to correctly update the framebuffer.
>
> There are mainly four reasons why it's so hard to make it work:
> [...]
The 4 reasons you gave are what, from an external point of view, were
already my conclusions.
But let me a take a real world example.
More than ten years ago---ten years!---I proposed to develop a software
solution for a certain task to an enterprise. The answer was: it will
take years to develop, we have not the time! There are current solutions
that can be adapted for the task.
Ten years later, I incidentally learned that they were still searching
for a solution to the problem since the existing solutions have never
managed to... solve the problem.
In the mean time I had developed a framework that made it easy to solve
the problem, not with years of development anymore (because these years
have already been spent developing the framework and not trying to
patch an existing Titanic---gigantic and sunking).
I do know that GPU is hard, trendy since the improvements in the CPU
is almost to a stand still, and is complex and that the industry is
making it even harder by not documenting things.
But I think the time spent, constantly, to try to make the thing sort
of work, while it is a code nightmare, is a waste of time.
What I'm proposing is:
1) Sever this DRM/KMS clearly from the kernel; that it is not on by
default and so that it can not hamper the kernel; and making, on the
kernel side, no decision "bended" concerning the display and the
framebuffer just in order to accommodate this DRM/KMS: do it totally
orthogonally and in order to make it the way
it seems logical, matching what the kernel has to achieve;
2) Audit the DRM/KMS code, going back to its source---Linux---without
the addition of FreeBSD own patching, that simply adds noise to what
seems to have already a poor noise/signal ratio, to see if we can sever
the end driving (your point #4) code from the rest of the gaz-work;
3) In all cases, design what seems to be logical, sound and maintainable
to deliver the service with the kernel, blending correctly with
the other tasks (and in fact, design "on paper"
without implementing something at first; the time spent on the paper
and trying to consider the problem from all the angles is time gained
when implementing or maintaining; and in this area the experience of
the ones who had been confronted to the "thing" will be invaluable to
say at least: "not like that!"); if the need for new kernel interfaces
arises, OK; but considering the kernel as a whole, with an interface
blending correctly with everything else and not mimicking something
else simply to be able to run the alien code;
4) If 2) has shown that the end part can be re-used, good. If not,
let's choose one good card (this means a card with "advanced" features
but with documentation) for a template driver and let the need
encourage people to write such a driver for the cards they want to
use with DRM support.
What is frightening me now, is that the impressive amount of work needed
to make the thing "work", and only temporarily, is a work that will
be lost because the code base will continue to evolve (not to say:
dissolve...).
And the feeling from your own description is that even you consider
that the code is not worth the effort because we will never be
sure that it can indeed work correctly.
If, instead of returning to the last CERL published version of GRASS, I
had wanted to "fix" GPL GRASS or if, instead of returning to the very
early (not GPL: Public domain indeed) web2c TeX utilities, I had wanted
to "fix" the current distribution, I would still be at it, or,
more probably, would have dropped the task after some years before
seeing the end of it.
--
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
