Re: DRM/KMS: countdown started

[tlaronde%polynum.com@localhost]

Le Thu, Jul 13, 2023 at 11:25:40AM +0000, Taylor R Campbell a écrit :
> > Date: Thu, 13 Jul 2023 11:35:50 +0200
> > From: tlaronde%polynum.com@localhost
> > 
> > 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 know you can just omit the drm drivers from the kernel, right?
> For example, on amd64:
> 
> no i915drmkms* at pci?
> no radeon* at pci?
> no nouveau* at pci?
> #no amdgpu* at pci?   # (not even enabled by default on amd64)
> 
> You can also disable them at boot-time with userconf, and you'll get a
> dumb pci framebuffer with genfb instead:
> 
>    > boot -c
>    userconf> disable i915drmkms
>    userconf> disable radeon
>    userconf> disable nouveau
>    userconf> quit
> 

Yes. But you have to specify all of them or know which one you will
encounter to disable it. This is what, from my POV, is wrong. This
should be possible to opt for it later and, at the minimum, the kernel
should be able to survive a problematic 2D setting by falling back to
a simple generic framebuffer. There are ways to circumvent the problem.
I want to try to address it.

> Same for the Arm boards that use the drm modesetting APIs, like
> tilcdc(4) and tifb(4).  But you'd have to rewrite all those drivers --
> and test them on a menagerie of Arm boards where the drm stuff has
> already been tested and works and has very small maintenance burden at
> this point.

That's the part I want to disentangle.

And, from my POV, the problem is not "maintenance" of existing/old.
It's the increasing burden of trying to follow upstream and to upgrade,
even simply to upgrade NetBSD part without having to touch DRM or
without being hampered by the present implementation creeping in the
kernel, or upgrade DRM/KMS without touching the rest of NetBSD.

And if the DRM/KMS stays with an "old" version, applications will not
work anymore because they are Linux centric and always go for "the
latest". And since the motto is "release often", the latest is every
other week.

> 
> I think you'll find you've misplaced where the painful parts of all
> this are, but go ahead...

Well, I know it will be painful ;-) That's why I have estimated 3 months
(not full time; but a significant part of my spare time).
-- 
        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