DRM removal soon

[Cy Schubert]

In message <20190228194929.GA18747 at troutmask.apl.washington.edu>, Steve 
Kargl w
rites:
> On Thu, Feb 28, 2019 at 11:22:52AM -0800, Cy Schubert wrote:
> > On February 28, 2019 11:15:11 AM PST, Steve Kargl <sgk at troutmask.apl.washin
> gton.edu> wrote:
> > >On Thu, Feb 28, 2019 at 10:49:51AM -0800, Cy Schubert wrote:
> > >> >
> > >> The ports work as advertised.  IMO graphics/drm-legacy should be
> > >> depreciated sooner than later. I would expect the graphics team
> > >> could better spend their time and energy on drm-current, which
> > >> btw works perfectly on my old laptop converted to i386 testbed,
> > >> than maintaining old bitrot. When can we expect drm-legacy to
> > >> finally be removed from ports?
> > >> 
> > >
> > >drm-legacy-kmd has already been *depreciated*?
> > >
> > >Perhaps, you meant deprecated.  :)
> > >
> > >Hopefully, never.  drm-current-kmod locks up my laptop.
> > >drm-legacy-kmod works.
> > 
> > Yes. drm-legacy-kmod should be removed from ports sooner
> > than later. drm-current-kind works perfectly on older gear
> > like my 13 year old Pentium-M, which was repurposed as an
> > i386 test platform years ago.
>
> Great drm-current-kmod works for you.
> drm-current-kmod DOES NOT work on my i386 laptop.

Hmmm. I could never get drm-legacy-kmod to work properly on my old 
Pentium-M laptop resorting to VESA. When I upgraded my main laptop 
(which also has an i386 partition and two amd64 partitions) to 
drm-current-kmod, rsyncing the i386 /usr/local, it worked with a minor 
tweak to xorg.conf.

Using drm-legacy-kmod on the old machine would initially freeze the 
display, ultimately freezing the whole machine. No such issues with 
drm-current-kmod.

>
> > The reason to remove old software from base is evident.
> > The same reason holds for ports as well. The ports team
> > are also a limited resource. 
>
> The drm-legacy-kmod port works.  It would never have been
> broken (and it would be unneeded) if the *working* drm2 code
> in base were never disconnected from the build.  The
> drm-legacy-kmod port would not have been broken for a month
> if an exp-run were done when modifications to pmap.h had
> been done.

The issue is developer time.

>
> I get it.  drm-current-kmod works for you, so lets penalize
> everyone else by removing working code. 

The graphics team supports four DRM ports. When FreeBSD-13 will be 
released that will become five. This is unsustainable. Additionally 
i386 and for that matter all 32-platform support has become an 
afterthought. More often than not it is 32-bit that breaks. This is 
especially true when what one expects to be a simple one line commit 
that works on amd64 totally hoses i386. drm-legacy-kmod was broken on 
i386 for a while for this very reason.

The amount of time I've personally spent dealing with my own i386 
breakage and worse, my pointing out i386 and legacy issues, time could 
have been better spent on productive work rather than maintaining 
software for an ever declining share of the platform pie.

Where do we want to spend our meager resources? That goes not only for 
src but ports too.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.