Date: Fri, 11 Aug 2023 09:13:43 -0600 From: Warner Losh <imp@bsdimp.com> To: Jan Beich <jbeich@freebsd.org> Cc: FreeBSD X11 <x11@freebsd.org> Subject: Re: DRM in base, again? Message-ID: <CANCZdfoOcoQNPD6XdbP2J7PTtF=HbU7XEH%2BAPBM%2B8yW8PmO48A@mail.gmail.com> In-Reply-To: <fs4p-snyy-wny@FreeBSD.org> References: <fs4p-snyy-wny@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000003a3d0b0602a729ec Content-Type: text/plain; charset="UTF-8" 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. > --0000000000003a3d0b0602a729ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Fri, Aug 11, 2023, 7:33 AM Jan Beich <<a href=3D= "mailto:jbeich@freebsd.org" target=3D"_blank" rel=3D"noreferrer">jbeich@fre= ebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Having drm-= kmod live in ports/ has problems:<br> - LinuxKPI sometimes breaking KBI on X.Y -> X.Y+1 upgrades which affects= <br> =C2=A0 binary packages during 3 months when both X.Y and X.Y+1 are supporte= d<br> - No uAPI thus Mesa, wlroots, chromium, etc. have to bundle <linux/dma-b= uf.h><br> - No KPI thus nvidia-drm has to bundle drm-kmod unlike other *-kmod ports<b= r> <br> and points of confusion:<br> - When drm-kmod was introduced it was supposed to evolve faster than<br> =C2=A0 FreeBSD but due unstable KPI upstream and lack of manpower to mainta= in<br> =C2=A0 conditionals only one drm-kmod for a given -RELEASE was usually supp= orted.<br> - While drm-kmod versions match Linux versions, FreeBSD support model[1]<br= > =C2=A0 makes it easy to pick a wrong FreeBSD version as kernel is rarely<br= > =C2=A0 upgraded independently from OS thus old major versions often cannot<= br> =C2=A0 support newer GPUs (except NVIDIA). For example, FreeBSD release not= es<br> =C2=A0 could document supported GPUs to help users decide.<br> <br> What's current status? Is it too late for the upcoming 14.0-RELEASE?<br= ></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Fre= eze is this week or next. So unless something is waiting in the wings, I= 9;m sure it's way way too late.</div><div dir=3D"auto"><br></div><div d= ir=3D"auto">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 bas= e might help with that, but you gotta have people working on updating to ma= ke things better... last time it was in base it was never updated and rotte= d.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Plus there are severa= l logistics issues. Some feel this is a good candidate for the first submod= ule 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 integ= rated with pkgbase.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto= ">And issues with gpl code. Manu was rewriting stuff...</div><div dir=3D"au= to"><br></div><div dir=3D"auto">And what about support for new gpu on old r= eleases. We'd love the ability to do that. While I think that's fin= e, we need to have the discussion as a community to get to that point. I th= ink there is enough consensus for it, but it won't be unanimous.</div><= div dir=3D"auto"><br></div><div dir=3D"auto">There's also installer int= egration issues to cope with.</div><div dir=3D"auto"><br></div><div dir=3D"= auto">And likely some other wildcard that nobody is seeing.=C2=A0</div><div= dir=3D"auto"><br></div><div dir=3D"auto">I don't say all that to take = a side. Just that there's a lot of issues to plow through. And freeze w= eek likely is far too late to start this for 14, but not too late for 15.</= div><div dir=3D"auto"><br></div><div dir=3D"auto">I think in base is a good= idea, but needs more than just manu working on it to make it a reality. An= d it's going tobtake more than just pure technical tasks to make it hap= pen. We need to get it documented. We need to drive the points of disagreem= ent to resolution and we likely need to recruit better for this. It's a= great goal, but not a simple path there.</div><div dir=3D"auto"><br></div>= <div dir=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto"= ><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <a href=3D"https://reviews.freebsd.org/D23085" rel=3D"noreferrer noreferrer= noreferrer" target=3D"_blank">https://reviews.freebsd.org/D23085</a>; and <= a href=3D"https://github.com/evadot/drm-subtree" rel=3D"noreferrer noreferr= er noreferrer" target=3D"_blank">https://github.com/evadot/drm-subtree</a><= br> appear inactive and limited to non-x86 drivers.<br> <br> --<br> [1] For comparison, OpenBSD releases twice a year from HEAD, bringing<br> =C2=A0 =C2=A0 newer WiFi and GPU drivers.<br></blockquote></div></div><div = dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div c= lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote></div></div></div> --0000000000003a3d0b0602a729ec--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoOcoQNPD6XdbP2J7PTtF=HbU7XEH%2BAPBM%2B8yW8PmO48A>