Re: DRM removal soon

On Thu, Feb 28, 2019 at 12:34:32PM -0800, Cy Schubert wrote:
> In message <[email protected]>, 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 <[email protected]
> > 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.
> 

Seems our experiences are exact opposites.  :(

I suppose it is the bane of those of who cannot afford
new hardware every 2 or 3 years.

> > > 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.
> 

Yes, I know all to well.  I started working on libm some
15 to 20 years ago because I need(ed) long double version
of the Bessel function routines.  Still, haven't found
the time to write those functions.

> >
> > 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.

I haven't looked at what the drm-fbsd11.2-kmod or 12.0 mean.  I assume
that these are the ports for 11-stable and 12-stable, and I assume
that these work on those specific stable branches.  If that is the
case, then there is no support needed by graphics teams unless a 
src committer merges somethings from -current that breaks stability.
If the MFC is a security fix, then the graphics teams may need to
asked about helping troubleshoot the 11.2 and 12.0 kmods; otherwise,
then MFC should not happen if it breaks stability.  Or, perhaps, 
I have a s different definition of 'stable.
 
-- 
Steve
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[email protected]"