Re: DRM/KMS

[David Brownlee <abs%netbsd.org@localhost>]

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

> 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?

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.

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?

> 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

David