DRM removal soon
Steve Kargl
sgk at troutmask.apl.washington.edu
Thu Feb 28 21:06:39 UTC 2019
On Thu, Feb 28, 2019 at 12:34:32PM -0800, Cy Schubert wrote:
> 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.
>
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
More information about the freebsd-arch
mailing list