Re: What is evdev and autoloading?

> On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > > On 2/18/19, Vladimir Kondratyev <vladimir_at_kondratyev.su> wrote:
> > > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > > >>> Anyone have insight into what evdev is?
> > > >> evdev.ko is a small in-kernel library that makes all your input events
> > > >> like keyboard presses libinput-compatible.
> > > > 
> > > > And libinput was created by the Freedesktop Wayland team to create
> > > > pressure on OS people to make their systems Wayland-compatible.
> > > > 
> > > >>> I do not need nor what these modules loaded.
> > > >> I think removing "option EVDEV_SUPPORT" from your kernel config should
> > > >> disable most of evdev.ko dependencies
> > > > 
> > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> > > > as libinput not be part of the standard packages?
> > > > 
> > > > The Freedesktop Wayland team consists of people with the Kay Sievers
> > > > mentality, which made Linus Torvalds ban his contributions. They do
> > > > not care about the bugs they introduce, forcing others to clean up the
> > > > mess they create.
> > > > 
> > > > I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> > > 
> > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
> > > input device handling in X and Wayland.  Not having it means that a lot 
> > > of input devices stop working, or work much worse.
> > > 
> > > We in the FreeBSD Graphics Team are working very hard to improve the 
> > > FreeBSD Desktop experience, since it is an avenue to recruit new users, 
> > > and make current users use FreeBSD more.
> > 
> > Sadly your execution on that seems to be missing the mark,
> > telling people they have to go get a port now to get drm working
> > because it could not be maintained in base, and then telling them,
> > oh, you need this new code in base so that it is so much easier
> > to use graphical stuff this way.
> > 
> > These seem to be conflicting stories.
> > 
> You are missing the point, one does not evolve as fast as the other, meaning
> one can be maintained within usual freebsd lifecycle, the other cannot or it
> becomes very painful.

So to ditch our 5 years support model, kick the code out of the tree and
make the users suffer?  The support model is suppose to be under review,
and IMHO, if kicking functional code out of the base system is to make
it possible to meet some support model we should defanitly take a very
close look at that issue.

The code has simply gone from being in base to a few git repositories
which are probably going to rot every time a breaking ABI change occurs
and we wend up with un happy users, un happy developers and bugmisters
who have to close bogus bug reports.

Have we really moved the state of the art forward by this action, simply
in the name of "we could not suppor that code?"

-- 
Rod Grimes                                                 rgrimes_at_freebsd.org