On Sun, 27 Mar 2022 12:33:34 -0600
Warner Losh wrote:
> On Sun, Mar 27, 2022 at 11:09 AM Pete Wright wrote:
>
> >
> >
> > On 3/25/22 21:42, Chris wrote:
> > > This probably isn't the correct list. But it's the closest of
> > > all the lists I'm subscribed to. Please forgive me.
> > > OK so here's what happened. I couldn't get the trackpad on a
> > > Dell laptop I just got to work in FreeBSD-13. So after a couple
> > > of days, I gave up and tried 12.3-STABLE r371721 today. Once I got
> > > the network (wifi) going. I pkg installed drm-kmod && it's depends.
> > > Added kld_list="amdgpu" to rc.conf && rebooted. The moment it
> > > loaded, the screen went black and it powered off. Booted to
> > > single-user, fsck && cp /var/log/messages to ~/ .
> > > I'm attaching a copy in case it sheds any light on the cause.
> > > The most interesting thing about all this, is that amdgpu
> > > worked flawlessly on 13 -- go figure.
> > >
> >
> > this discussion is probably best suited for the freebsd-x11 mailing
> > list, but i think you can try a couple things:
> >
> > - give NomadBSD a spin (https://nomadbsd.org/). it's a live USB image
> > that does a really good job at auto-detecting hardware and giving you
> > nice desktop. it's based on freebsd-13.0. you can also install it on
> > your disk if everything looks good. i frequently use it to test
> > hardware support on new systems i encounter.
> >
> > - it's hard to tell without any hardware info provided, but its possible
> > you have an older AMD gpu, as such you might want to try using radeonkms
> > in rc.conf rather than amdgpu.
> >
> > if neither of those things help i'd definitely suggest subscribing to
> > the freebsd-x11@ mailing list to get the appropriate eyes on things:
> > https://lists.freebsd.org/subscription/freebsd-x11
> >
>
> I'd like to share with people that I'm working on a statement of what works
> and what the graphics team will spend a lot of effort on vs continue to have
> build support in the tree.
>
> The short version is that the latest stable branch, the latest current and
> the
> last most-recent release will be the ones best supported. Anything older
> than that (prior stable branches, even those supported by the rest of the
> project) may work great, but may also be broken or perform less well or
> support fewer newer graphics cards. In addition, cards older than about
> a decade may stop working on an upgrade because upstream's attention
> to these isn't so great or the driver is a binary driver that the upstream
> vendor
> has not upgraded to support its older cards with newer interfaces, etc.
> Short of doubling or tripling the graphics team size (volunteers welcome),
> it's too
> hard to commit to more than this limited subset of support. Even with a
> larger
> active developer group, expanding beyond this envelope would be hard given
> the size of the testing matrix...
I do confirm the above.
I'll also say that currently the graphics team is just me and wulf@
(and sometimes small contribution from others), we can't do everything.
> Also, I don't think we've ever supported unloading the drm drivers, so it's
> not
> too surprising that didn't work.
It used to work for i915kms, it never worked for amdgpu.
I'm (well $WORK) is interested in unloading mostly for GPU-passthough.
That will allow one user to boot FreeBSD, use the graphics, unload the
module and start a Windows VM or whatever, use the graphics in it and
after shutting down the VM one could use again the GPU on FreeBSD.
It's a bit low on my todo list though.
> Also, I know the older hardware thing is hard to swallow. I get that people
> want
> that stuff to work forever because it performs adequately. However, we are
> heavily
> dependent on leveraging the work of others to support what we can, so when
> the
> work we depend on starts to bitrot, our support for that hardware suffers
> as well...
>
> Warner
>
>
> > -pete
> >
> > --
> > Pete Wright
> > p...@nomadlogic.org
> > @nomadlogicLA
> >
> >
> >
--
Emmanuel Vadot
