tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: DRM/KMS
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...)
David
Home |
Main Index |
Thread Index |
Old Index