What is evdev and autoloading?

[Warner Losh]

On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
freebsd-rwg at pdx.rh.cn85.dnsmgr.net> wrote:

> > 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?"
>

I don't know. I think the fact that drm2 doesn't support anything newer
than 5-year-old hardware is a pretty convincing evidence that the old way
is broken and doesn't work.

Warner