Re: DRM in base, again?

On Fri, Aug 11, 2023, 7:33 AM Jan Beich <jbeich@freebsd.org> wrote:

> Having drm-kmod live in ports/ has problems:
> - LinuxKPI sometimes breaking KBI on X.Y -> X.Y+1 upgrades which affects
>   binary packages during 3 months when both X.Y and X.Y+1 are supported
> - No uAPI thus Mesa, wlroots, chromium, etc. have to bundle
> <linux/dma-buf.h>
> - No KPI thus nvidia-drm has to bundle drm-kmod unlike other *-kmod ports
>
> and points of confusion:
> - When drm-kmod was introduced it was supposed to evolve faster than
>   FreeBSD but due unstable KPI upstream and lack of manpower to maintain
>   conditionals only one drm-kmod for a given -RELEASE was usually
> supported.
> - While drm-kmod versions match Linux versions, FreeBSD support model[1]
>   makes it easy to pick a wrong FreeBSD version as kernel is rarely
>   upgraded independently from OS thus old major versions often cannot
>   support newer GPUs (except NVIDIA). For example, FreeBSD release notes
>   could document supported GPUs to help users decide.
>
> What's current status? Is it too late for the upcoming 14.0-RELEASE?
>

Freeze is this week or next. So unless something is waiting in the wings,
I'm sure it's way way too late.

We have a lot of wifi drivers in base already. There is a fair amount of
work to coordinate updating the kpi emulation. Putting drm in base might
help with that, but you gotta have people working on updating to make
things better... last time it was in base it was never updated and rotted.

Plus there are several logistics issues. Some feel this is a good candidate
for the first submodule use, which has a number of implications for docs
and build integration apart from any issue with drm itself. Others feel
that this is better integrated with pkgbase.

And issues with gpl code. Manu was rewriting stuff...

And what about support for new gpu on old releases. We'd love the ability
to do that. While I think that's fine, we need to have the discussion as a
community to get to that point. I think there is enough consensus for it,
but it won't be unanimous.

There's also installer integration issues to cope with.

And likely some other wildcard that nobody is seeing.

I don't say all that to take a side. Just that there's a lot of issues to
plow through. And freeze week likely is far too late to start this for 14,
but not too late for 15.

I think in base is a good idea, but needs more than just manu working on it
to make it a reality. And it's going tobtake more than just pure technical
tasks to make it happen. We need to get it documented. We need to drive the
points of disagreement to resolution and we likely need to recruit better
for this. It's a great goal, but not a simple path there.

Warner

https://reviews.freebsd.org/D23085 and https://github.com/evadot/drm-subtree
> appear inactive and limited to non-x86 drivers.
>
> --
> [1] For comparison, OpenBSD releases twice a year from HEAD, bringing
>     newer WiFi and GPU drivers.
>