Ars Technica article

[Niclas Zeising]

On 2020-04-13 09:50, Alexey Dokuchaev wrote:
> On Mon, Apr 13, 2020 at 01:11:30AM -0600, Warner Losh wrote:
>> ...
>> 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.
> 
> Mind that you're talking about hardware just several years old; it's just
> as relevant for its users who bought their laptop like myself ~four years
> ago and now you're telling them (us) that you intend to remove the only
> working DRM port.  This is certainly not the way to attract more FreeBSD
> desktop users; in fact, you'll likely get exactly the opposite.

drm-legacy-kmod's days have been numbered for far longer than when the 
drm-legacy-kmod port was created.  It's days was numbered even when it 
was part of the FreeBSD base system, it never saw any updates, and the 
hardware support was lacking.  All that ever happened was updates to 
keep it compiling and hopefully running.

The new lkpi based drm drivers (drm-kmod) were created to move driver 
support forward, so that we could get support for newer hardware.  Doing 
it this way also meant that we have a chance to pull in updates and keep 
on supporting newer hardware.  While there are some warts, and some 
cases, especially on non-amd64 hardware, where drm-legacy-kmod might 
work better, the goal has always been to remove it completely.

> 
>> My reading of that PR is why xf86-video-ati-legacy was created.
> 
> Not really: hardware cursor got broken between versions 18->19, while
> legacy port tracks 7.9.0.  I guess it should not be too hard to diff the
> drivers' source code and try to figure out what had changed, I'd look
> into this.

xf86-video-ati-legacy was created when we update dxf86-video-ati to a 
newer version, explicitly in order to cater for drm-legacy-kmod users. 
We needed to update xf86-video-ati to get support in X for newer 
hardware, and when we got reports about there being issues with the 
updated video-ati, we created the -legacy version as a stop-gap measure. 
  Now we have come to a point where we can't support that version, since 
it does not work with xserver 1.20.  I spent some time to try to create 
a version that could work, but as has been pointed out by you and 
others, I didn't succeed.  Unfortunately, I don't have the time or 
hardware to dig deeper into this, so if you need this, then you have to 
work together with Andrea Venturoli to see if you can get it working.

The cursor issue was found when we updated from xf86-video-ati 18.0 to 
19.0.  There is a workaround, which is to use the sw cursor.  I do not 
know if using the modesetting xorg driver works, but that could also be 
a solution.

> 
>> I know you're looking for someone to blame. That person isn't Niclas.
> 
> Oh, I'm not blaming him at all.  And more to it, while Andrea Venturoli
> is currently helps to debug xf86-video-ati-legacy issues, I'm not that
> concerned about that driver, but rather that all other DRM ports except
> legacy locking up my laptop upon "kldload radeonkms".  This isn't right;
> it should be debugged and fixed, and only then drm-legacy-kmod port can
> be removed.

Thank you for volunteering to help debug and fix why radeonkms locks up 
your laptop.

Regards
-- 
Niclas Zeising
FreeBSD Graphics Team