Ars Technica article

Warner Losh imp at bsdimp.com
Mon Apr 13 07:11:46 UTC 2020


On Sun, Apr 12, 2020, 11:24 PM Alexey Dokuchaev <danfe at freebsd.org> wrote:

> [ setting CC to a more appropriate -x11@ list ]
>
> On Sat, Apr 11, 2020 at 12:43:00AM +0000, Niclas Zeising wrote:
> > ...
> > Short answer, because I'm on my phone... You shouldn't use drm-legacy-
> > kmod, it is on life support.
>
> Well, that's funny, considering that for many people, it is the only
> DRM port that actually works.
>

To be blunt: drm-legacy-kmod's days are numbered. It's irrelevant that it's
the only one that "works." It's a distraction to keeping drm-kmod working
on newer, more relevant hardware. It's unfortunate that some older hardware
has stopped working with the newer code, but much of that is due to
upstream pressures. xf86-video-ati-legacy is one symptom of that problem:
upstream has moved on and we simply do not have the resources to band-aide
together support for the old hardware forever.

Let me be blunt: it's my goal to remove drm-legacy-kmod as quickly as
possible. It's a big drag on the graphics team's time and has low ROI for
the project. Given the challenges we have today, I see no other sane course
of action. People that have broken hardware need to step up and provide
fixes for that old hardware in the drm-kmod context, or buy new hardware.
That's the harsh reality we have with the people we have working in this
area.

> The drm-legacy-kmod radeonkms.ko module requires xf86-video-ati-legacy
> > to work in menu cases,
>
> menu == many? Where is this requirement documented?  Many people had

reported having to use `graphics/drm-legacy-kmod' ('cause, well, nothing
> else works) and radeonkms.ko together with `x11-drivers/xf86-video-ati',
> particularly, in PR 237642* about the invisible mouse pointer


My reading of that PR is why xf86-video-ati-legacy was created. People
upgraded and had to revert to the old version of xf86-video-ati to get it
working and reported that xf86-video-ati-legacy worked.

And that's the problem: we can't keep growing new legacy things. The cards
reported were from 2008. That's over a decade old. Given the choice between
supporting such old hardware, and newer hardware, the new hardware wins.
It's an unfortunate reality, but honestly, upstream broke the support of
the older cards. There's been no patches against the latest version of
upstream, nor any work to make the drm-kmod drivers work with the older
hardware. The older hardware isn't readily available, and the ROI for
working on it is really really low compared to other thigns that could  be
done.

> and that has been broken since the update of xorg-server, with no one
> > stepping up to test my patches for it.
>
> Wrong: both pfg@ and me did test those patches, as well as other people
> who reported it on -x11@ list, with sad results unfortunately. :-(
>

So Niclas tried to do something to make it work for you, but it didn't
work. He's already gone the extra mile for this old hardware, and it's
unfortunate that it no longer works. I know you're frustrated. I know
you're looking for someone to blame. That person isn't Niclas. It's xorg
upstream which has broken support for these older cards in some way with
the old DRM drivers. They no longer support the vintage of driver we have
in drm-legacy-kmod. We're lucky it works as well as it does, honestly.

> I'm using modesetting across three different Intel GPUs without seeing
> > any issues.
>
> Yes, lots of people apparently are happier with X11 server's built-in
> "modesetting" driver rather than traditional xf86-video-*, but doesn't
> modesetting drivers lack some/any 3D acceleration?  I don't see this
> documented on wiki.freebsd.org/Graphics (and modesetting driver is only
> mentioned in the Intel section).


The modesetting driver is working with my kaby lake laptop. I'm quite happy
that I can get a modern laptop and have things work. Given the choice
between really old hardware and current hardware, current hardware has to
win when there's a resource shortage. And we have a huge resource shortage
in this part of the stack: the drm-kmod maintainer's job shifted so he's
had to resign from that role. We have nobody to even update to newer Linux
driver versions (though we might have a promising person in the wings).
There's literally nobody that has the time, the hardware, the docs and the
expertise to help with this older video hardware (at least as evidence of
it's remaining broken for a long, long time). Until that person shows up,
you will unfortunately be out of luck.

Again, I hate to be harsh, but supporting this old gear is getting in the
way of supporting other things. It's becoming clear to me, at least, that
it's time to cut our losses on anything over a decade old. It's time we're
clear about it. We had our hand forced for nvidia cards when we upgraded to
1.20 because the older cards binary driver no longer works with 1.20 and
nvidia has said they can't support them any more. We, sadly, must do the
same and so drm-legacy-kmod's days are severely numbered because it's
become a huge time sink with very little benefit.

Warner

./danfe
>
> *) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237642
> _______________________________________________
> freebsd-x11 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
>


More information about the freebsd-x11 mailing list