What is evdev and autoloading?

[Warner Losh]

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

> > 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.
>
> But it DOES work, I am pretty sure we have 1000's of users on that 5 year
> old hardware that are totally happy with the in tree DRM2 that is in
> stable/12,
> and some of whom have ventured into head/13 are having issues with the
> "new" model (ie kmod broken by a base commit).


First off, current is current. Second, they have two different drm modules
to choose from. The drm-legacy stuff was broken by a commit to base, but
even if it had been in base, and connected to the build, it would have been
broken. kib would have fixed the compile issue (which we did fix in github
almost as soon as it happend). However, the semantic issue he wouldn't have
seen because he wouldn't have actually tested the setup that's broken
because he doesn't have it.

So please stop saying it does work. It does not work. It was silently
broken by kib's changes. The compile issue is a red herring.  You'd be
fighting the same issue in current if it was connected to the build. It's
literally the same code.


> I know that there is wip
> to get CI coverage for that, but wip is wip, and we need to start changing
> the cart horse driver order we keep doing and get things right.  Port
> up and working, with CI testing *before* we go remove kmod'ed code from
> base would be a much more appropriate path.
>
> I think one serious problem here is the summary dismissal of things
> simply on the "5 year old" basis.  Not everyone, and infact few now
> a days other than corporate buyers, can afford new hardware,
> giving the minimal performance increase in systems over the last 5
> years the cost/benifit factor of a new computer is just too low


No you are purposely mischaracterizing what's going on here.

Nobody is being dismissive of 5 year old hardware. You are
mischaracterizing what I'm saying. Please stop.

What I'm being dismissive about is that drm2 only supports 5 year old
hardware. Not because the hardware is broken, but because the model we used
to keep in the tree is broken. Newer hardware just isn't supported at all
by it. That's the problem we're trying to fix. drm2 only supporting old
hardware is a bigger problem.

Read another way, our support model is so broken that we can't support
anything newer than 5 year old hardware in drm2. It's our inability to move
faster in base that I'm dissing here, not the hardware. We're transitioning
to a newer / better model. There are bumps along the way.

ne of the long standing features of running a BSD is that it could
> stretch very good life out of hardware, and imho it would be in our
> best interest to try and keep that.   And we do in most aspects,
> though recently in some hardware testing OpenBSD beat us in several
> cases of "just booted and worked" on several pieces of hardware
> that came accross my bench for data recovery.  FreeBSD would not
> even boot, or paniced early in the kernel :-(  None of these systems
> was older than a P4.
>

If you can't handle the bumpiness of -current, you can run stable/12. You
can also run any of the 64-bit hardware. It all still works. 32-bit laptops
haven't been mainstream in even longer, so none of the developers have
them. They are kinda hard to come by, so things don't get tested. When
things aren't tested, other changes in the system break them.

Warner