Re: DRM/KMS

[tlaronde%polynum.com@localhost]

Le Fri, Jul 07, 2023 at 08:02:22PM +0100, David Brownlee a écrit :
> On Fri, 7 Jul 2023 at 18:19, <tlaronde%polynum.com@localhost> wrote:
> >
> > Le Fri, Jul 07, 2023 at 03:08:25PM +0100, David Brownlee a écrit :
> > > On Fri, 7 Jul 2023 at 15:03, Martin Husemann <martin%duskware.de@localhost> wrote:
> > > >
> > > > On Fri, Jul 07, 2023 at 02:30:14PM +0100, David Brownlee wrote:
> > > > > drm/kms definitely is hugely complicated, overly Linux focussed, and
> > > > > difficult to maintain and update. A lot of effort has been put into
> > > > > getting it to run on NetBSD (and updating from previous versions), but
> > > > > it's currently the only viable game in town.
> > > >
> > > > I also thing it is not *that* far away from working fine.
> > > >
> > > > The releng wiki page lists a bunch of PRs against it, but those are mostly
> > > > hard to fix because the problem only happens on *some* hardware, and
> > > > sometimes only in special scenarios (e.g. serial console used and the
> > > > monitor powered on during drm/kms attaching).
> > > >
> > > > That it all is a mess we probably all agree with.
> > > >
> > > > And this will require more updates, every year - GPU hardware does
> > > > evolve, and available options change.
> > > >
> > > > Using no drm/kms is a good alternative (and works great on NetBSD in general).
> > > > But you loose WebGL and sometimes accalerated video playback, and also
> > > > often support for mulitple displays (but that part might even be easy to fix).
> > >
> > > So far some good changes (cribbing shamelessly from other suggestions) might be:
> > > - Implement "boot -D" (or similar) to boot with all DRM disabled, to
> > > make it easier for hardware with issues
> > > - Allow optionally initialising DRM after boot and transferring
> > > console ownership (may add more work in future upgrades, but works
> > > well with above item :)
> > > - Rework wsdisplay to try to reduce abstraction violations and make it
> > > cleaner to work with
> > > - Looking at issues with certain hardware (can probably find systems
> > > to ship if anyone is interested...)
> >
> > The 1), 2) and a part of 3) is what I have in mind for the first step.
> 
> Would this be from the three bullet points above? (In which case,
> wonderful, let me get out of your way :), or your original numbered
> points, in which case I'll may respond later

This is from your 3 points above. Obviously, the 3) will be only
partially made since I will have only one side of the view.

> 
> > As far as I'm concerned, I will not help to "fix" the present state of DRM/KMS
> > since for me the amount of work already needed to try to make the thing work is
> > out of proportion and will have to be doubled the next time; this is, already
> > and even more so for the future, hopeless.
> 
> There are certainly different aspects to fixing the present state of
> DRM/KMS. Working directly on the existing DRM code is definitely
> useful, but very much not the only need.
> 
> I'm just trying to make related suggestions that are likely to be of
> immediate benefit to NetBSD and picked up quickly and imported into
> the tree, plus feedback on your earlier comments (with the same aim).
> Obviously you're at liberty to give each as much (or little)
> consideration as you choose!
> 
> >From your earlier email:
> 
> 1) Sever this DRM/KMS clearly from the kernel [...]
> 
> As alluded to earlier, for ~any hardware on which the kernel can run
> with DRM enabled, it can run without DRM (with reduced functionality).
> Cleaning up the interface between the DRM and the rest of the kernel
> (I'm just going to wave hands and say "wsdisplay") would definitely be
> of some benefit. Would I be correct in assuming this would include
> making the existing DRM "more pluggable" while trying not to impede
> future upstream merges - to allow other things (see 4) to be
> conditionally in its place?

Yes. My general view of the thing is that a kernel is in fact a general
resources manager, implementing a policy for resources sharing, without
any specialization (as a file system orders files without caring what
is in them).

There can be co-processing units for specialized tasks, like Auxiliary
Graphical Processing Units, that can be hardware or software (with
almost any combination in between hardware and software).

So the aim is that the AGPUs can be discovered, listed, and use if
wanted, but supplementary to the kernel; aside or whatever the term
might be. With a pure software basic AGPU being always or almost
always at disposal---there can perfectly be a computer that has only
0D display (isolated leds: "works, doesn't work") or a line of display
1D. AGPU starts at 2D.

And to make things so that some kind of protocol is put between the
kernel and the AGPU so that changing an AGPU has as little impact to the
kernel as possible and that the work can be done almost independently.

Would it be possible and to what extent? This is the question I want to
answer now.

> 
> 2) Audit the DRM/KMS code, going back to original source---Linux--- [...]
> 
> This is likely to be a significant project, and may well yield some
> interesting and useful findings, but it would be likely to take quite
> some time, and I might suggest there are other aspects which would
> yield more immediate benefit first.

This will not be done at first. At first, I will go only in the details
of the DRM/KMS code to allow to orthogonalize things. This is where I
will need the help of the history to entangle things.
 
> 
> 3) In all cases, design what seems to be logical, sound and
> maintainable to deliver the service with the kernel, blending
> correctly [...]
> 
> This would be more of an underpinning philosophy on how to approach
> the project? I have absolutely nothing to say against this :)
> 
> 4) If 2) has shown that the end part can be re-used, good. If not,
> let's choose one good card [...]
> 
> It's good to have a fallback :) Again, would this include making
> "wsdisplay" more pluggable for the existing and this potentially new
> DRM implementation?
> 

Yes. But the answer doesn't mean much since I have for the moment too
little knowledge about how the things interact...

> > So I maintain the offer and thanks David Brownlee for the offer to send
> > me the CVS (and yes, the git and hg would be worth too) but since I try
> > to make a small donation every year to NetBSD it will not "cost" me
> > something I was not already planning to give, so I ask the core to make
> > the estimation and once I have donated, if David is doing the work, to
> > make things so that at least, he gets back what it has costed him to
> > make and send me the copy I have requested.
> 
> If martin is happy to ship from within the Euro zone then I'm happy to
> defer from my "close but no longer in due to political stupidity"
> location... :)
> 
> But if I can help in any other way, just let me know
> 

Thanks again for the proposal! But I will enjoy my week-end now, since
the count down is about to start ;-)
-- 
        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