Re: [RFC] Deprecation and removal of the drm2 driver

On Tue, May 22, 2018 at 8:50 AM, Johannes Lundberg <johalun0_at_gmail.com>
wrote:

> On Mon, May 21, 2018 at 23:50 Steve Kargl <sgk_at_troutmask.apl.washington.
> edu>
> wrote:
>
> > On Mon, May 21, 2018 at 03:20:49PM -0700, K. Macy wrote:
> > > >
> > > > I just ask.
> > > > Or why not include drm-next to base svn repo and add some
> > > > option to make.conf to swith drm2/dem-next ?
> > >
> > > Even if it's not being built on amd64 we're still responsible for
> > > keeping it building on !amd64 so long as it's in base. This makes
> > > changing APIs and universe runs more burdensome. The graphics
> > > developers have given you notice that it will now be your collective
> > > responsibility to keep it up to date.
> > >
> >
> > Not quite.  One graphics developer has indicated a desire
> > to remove working code, because it interferes with the
> > graphics developers' port on a single architecture.  There
> > is no indication by that graphics developer that drm2 will
> > be available in ports.  You can go read the original post
> > here:
> >
> > https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
> >
> > The last paragraph is
> >
> >    What does the community think?  Is there anyone still using
> >    the drm2 driver on 12-CURRENT?  If so, what is preventing
> >    you from switching to the port?
> >
> > The answer to the last two questions are "yes" and "the port
> > does not work on i386".
> >
> > Yes, I recognize that you're clever enough to purposefully
> > break the API so that you can thumb your nose at those of
> > us who have older hardware.
> >
> > What is wrong with using
> >
> > .if ${MACHINE_ARCH} != amd64
> > ...
> > .endif
> >
> > to enable/disable drm2?
>
>
>
> The answer to the first question is that the consensus seem to be that
> moving to a port is best for the _majority_.
>
> Let me ask you, what’s wrong with this one-liner after base install
> pkg install drm2
> ?
>
>
> >
> > --
> > Steve


Hello,

If you were running GNU/Linux, you would be using the equivalent of
drm-stable-kmod or drm-next-kmod. Why do you want to run older code on
FreeBSD?

Hardware and software moves on. One does not expect to run the latest
hardware with old software, old hardware and new software might work, if
someone is willing to maintain old code.

Since the proposal was to keep drm2 in 11, you're looking at support until
2021, will you still run that old hardware then?

With such long-time support offered by 11- branch, why hamper development
of 12 by lugging around old, hard to maintain code that is relevant for
only legacy hardware?

Best regards
Andreas