From nobody Fri Aug 11 15:13:43 2023 X-Original-To: x11@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RMnPf5C55z4Twt1 for ; Fri, 11 Aug 2023 15:13:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RMnPf3NVqz4WTJ for ; Fri, 11 Aug 2023 15:13:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-522dd6b6438so2599323a12.0 for ; Fri, 11 Aug 2023 08:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691766835; x=1692371635; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XjfTf7Ws4sz3vAYOQVfH4wzCLh26XpgJJiukkw7L458=; b=xnq2cQngpNDqcUOBKOs0FI870wko2cAsPOmsHwSHWkR5ynN5dMAlUlP7fp/p864ISJ eyseBt5cNfD8hnTsIxgsm5GcX11Ov1Zi+G+9Er+OCw5hO3prTtmzuXUH/fRksJU1ghmM bzkW3ElX8MaVa3nWv0myt5oMyQu/QqiPqhQym8W/+UN0UQsDMYcAhCGOxFRedD/3nPSv k30kJg9xUEsbXLajvVXy8286N3gWvekxzNYC+LbMY+4KhuDPPUbrVqJFxI5G8E44rx7g +FUaQdT9vxZytKtvvQJiW1WgE2/6nHkrO61LU569ANl7JpdnKQlNzBuKUpxJOvl7xICU 98pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691766835; x=1692371635; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XjfTf7Ws4sz3vAYOQVfH4wzCLh26XpgJJiukkw7L458=; b=EU3liyXn6kv+9g/bqzsDS3PCN1yyzRHnDY4emHTq4Srdm1i7v1V14MbNTErxsGGWhB iEUi8Euk0rNxfDJd4zk7dzxU88sY+GN9Nh6nsR6zW/PYt/yt+qkbEHCE7ngIgniZ2kqs w7v8nGKx4oDBeTc+OwdHyeqOv+8/sB6w4imc4OoNPh0v5bIEISf3wz7h4fieBxTpY0Ij EK51xO+znC7q4g458E1uvOTVOTlOegxeiT2fN3gDzwb0ni29QrqSJYkB9LavbNgr+Pa0 icrjV8zRmXu74+3iMWr1jNkbub8OhOsSGJfHrTtYnsmu0LJHVFQgfTomiLovej32KZ6H McHQ== X-Gm-Message-State: AOJu0YxmpzNM6avYa7i2YFecGyKROEMiuwb69gpvPwwscJ1ackOKE43P 7Cd3rlpFbL3o2qyOK+iNqdS0BSsWwrMAqTBySue+zZfr0TDuCG/l X-Google-Smtp-Source: AGHT+IETXPDpH94/sMVfdFzEUo/bEsqpDpzMs1kr5krEw9YX8fELGPH1rdsvgZws55lKcLEka42KR3XfM2oWWdVX0W8= X-Received: by 2002:aa7:d852:0:b0:523:b665:e494 with SMTP id f18-20020aa7d852000000b00523b665e494mr1628945eds.15.1691766834734; Fri, 11 Aug 2023 08:13:54 -0700 (PDT) List-Id: X11 List-Archive: https://lists.freebsd.org/archives/freebsd-x11 List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 11 Aug 2023 09:13:43 -0600 Message-ID: Subject: Re: DRM in base, again? To: Jan Beich Cc: FreeBSD X11 Content-Type: multipart/alternative; boundary="0000000000003a3d0b0602a729ec" X-Rspamd-Queue-Id: 4RMnPf3NVqz4WTJ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --0000000000003a3d0b0602a729ec Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2023, 7:33 AM Jan Beich 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 > > - 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


On Fri, Aug 11, 2023, 7:33 AM Jan Beich <jbeich@fre= ebsd.org> wrote:
Having drm-= kmod live in ports/ has problems:
- LinuxKPI sometimes breaking KBI on X.Y -> X.Y+1 upgrades which affects=
=C2=A0 binary packages during 3 months when both X.Y and X.Y+1 are supporte= d
- No uAPI thus Mesa, wlroots, chromium, etc. have to bundle <linux/dma-b= uf.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
=C2=A0 FreeBSD but due unstable KPI upstream and lack of manpower to mainta= in
=C2=A0 conditionals only one drm-kmod for a given -RELEASE was usually supp= orted.
- While drm-kmod versions match Linux versions, FreeBSD support model[1] =C2=A0 makes it easy to pick a wrong FreeBSD version as kernel is rarely =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
=C2=A0 could document supported GPUs to help users decide.

What's current status? Is it too late for the upcoming 14.0-RELEASE?

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.

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.

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

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

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 dir=3D"auto">
There's also installer int= egration issues to cope with.

And likely some other wildcard that nobody is seeing.=C2=A0

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.

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.

=
Warner

https://reviews.freebsd.org/D23085 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<= br> appear inactive and limited to non-x86 drivers.

--
[1] For comparison, OpenBSD releases twice a year from HEAD, bringing
=C2=A0 =C2=A0 newer WiFi and GPU drivers.


--0000000000003a3d0b0602a729ec--