What is evdev and autoloading?

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

What is evdev and autoloading?

Steve Kargl
Anyone have insight into what evdev is?  There appears to
be no manual page.  When I reboot a system with custom
kernel, the system is autoloading evdev.ko, uhid.ko, and
wmt.ko.  I do not need nor what these modules loaded.
How does one prevent this autoloading?

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

freebsd-hackers mailing list


On 2019-Feb-17, at 10:03, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:

Anyone have insight into what evdev is?  There appears to
be no manual page.  When I reboot a system with custom
kernel, the system is autoloading evdev.ko, uhid.ko, and
wmt.ko.  I do not need nor what these modules loaded.
How does one prevent this autoloading?

Looking via the web lead to:

https://www.freebsd.org/cgi/man.cgi?query=evdev&apropos=0&sektion=4&manpath=FreeBSD+12.0-RELEASE&arch=default&format=html
So:

NAME
       evdev - Generic Linux input driver

SYNOPSIS
       Section "InputDevice"
         Identifier "devname"
         Driver "evdev"
         Option "Device"   "devpath"
         Option "Emulate3Buttons"     "True"
         Option "Emulate3Timeout"     "50"
         Option "GrabDevice" "False"
         ...
       EndSection

DESCRIPTION

        evdev is an Xorg input driver for Linux's generic event devices. It
        therefore supports all input  devices  that  the kernel knows about,
        including most mice, keyboards, tablets and touchscreens. evdev
        is the default driver on the major Linux distributions.
. . .



but it seems to not have a 13-current entry. It does have
a 12.0-RELEASE entry.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Steve Kargl
On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote:

>
>
> On 2019-Feb-17, at 10:03, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
>
> Anyone have insight into what evdev is?  There appears to
> be no manual page.  When I reboot a system with custom
> kernel, the system is autoloading evdev.ko, uhid.ko, and
> wmt.ko.  I do not need nor what these modules loaded.
> How does one prevent this autoloading?
>
> Looking via the web lead to:
>
> https://www.freebsd.org/cgi/man.cgi?query=evdev&apropos=0&sektion=4&manpath=FreeBSD+12.0-RELEASE&arch=default&format=html
> So:
>
> NAME
>        evdev - Generic Linux input driver
>
> DESCRIPTION
>
> evdev is an Xorg input driver for Linux's generic event devices. It
> therefore supports all input  devices  that  the kernel knows about,
> including most mice, keyboards, tablets and touchscreens. evdev
> is the default driver on the major Linux distributions.
> . . .
>
>
>
> but it seems to not have a 13-current entry. It does have
> a 12.0-RELEASE entry.
>

Thanks.  Kinda odd that freebsd-current doesn't have a manual
page, but FreeBSD-12 does.

I have a wireless logitech mouse.  It seems that the
wireless USB dongle is causing the load of the modules.
I still understand why as ums(4) does not should a
dependency on uhid, wmt, or evdev.

--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Rodney W. Grimes-4
> On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote:
> >
> >
> > On 2019-Feb-17, at 10:03, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
> >
> > Anyone have insight into what evdev is?  There appears to
> > be no manual page.  When I reboot a system with custom
> > kernel, the system is autoloading evdev.ko, uhid.ko, and
> > wmt.ko.  I do not need nor what these modules loaded.
> > How does one prevent this autoloading?
> >
> > Looking via the web lead to:
             ^^^^^^^^^^^^^^^
web lies

> >
> > https://www.freebsd.org/cgi/man.cgi?query=evdev&apropos=0&sektion=4&manpath=FreeBSD+12.0-RELEASE&arch=default&format=html
> > So:
> >
> > NAME
> >        evdev - Generic Linux input driver
> >
> > DESCRIPTION
> >
> > evdev is an Xorg input driver for Linux's generic event devices. It
> > therefore supports all input  devices  that  the kernel knows about,
> > including most mice, keyboards, tablets and touchscreens. evdev
> > is the default driver on the major Linux distributions.
> > . . .
> >
> >
> >
> > but it seems to not have a 13-current entry. It does have
> > a 12.0-RELEASE entry.
> >
>
> Thanks.  Kinda odd that freebsd-current doesn't have a manual
> page, but FreeBSD-12 does.

rgrimes@t400:~ % man evdev
No manual entry for evdev
rgrimes@t400:~ % man -k evdev
apropos: nothing appropriate
rgrimes@t400:~ % uname -a
FreeBSD t400.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE GENERIC  amd64
rgrimes@t400:~ %
There is no man page for evdev in 12.0-RELEASE

>
> I have a wireless logitech mouse.  It seems that the
> wireless USB dongle is causing the load of the modules.
> I still understand why as ums(4) does not should a
> dependency on uhid, wmt, or evdev.
>

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Ian Lepore-3
In reply to this post by Steve Kargl
On Sun, 2019-02-17 at 16:24 -0800, Steve Kargl wrote:

> On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote:
> >
> >
> > On 2019-Feb-17, at 10:03, Steve Kargl <sgk at
> > troutmask.apl.washington.edu> wrote:
> >
> > Anyone have insight into what evdev is?  There appears to
> > be no manual page.  When I reboot a system with custom
> > kernel, the system is autoloading evdev.ko, uhid.ko, and
> > wmt.ko.  I do not need nor what these modules loaded.
> > How does one prevent this autoloading?
> >
> > Looking via the web lead to:
> >
> >
https://www.freebsd.org/cgi/man.cgi?query=evdev&apropos=0&sektion=4&manpath=FreeBSD+12.0-RELEASE&arch=default&format=html

> > So:
> >
> > NAME
> >        evdev - Generic Linux input driver
> >
> > DESCRIPTION
> >
> > evdev is an Xorg input driver for Linux's generic event
> > devices. It
> > therefore supports all input  devices  that  the kernel kn
> > ows about,
> > including most mice, keyboards, tablets and touchscreens. evdev
> > is the default driver on the major Linux distributions.
> > . . .
> >
> >
> >
> > but it seems to not have a 13-current entry. It does have
> > a 12.0-RELEASE entry.
> >
>
> Thanks.  Kinda odd that freebsd-current doesn't have a manual
> page, but FreeBSD-12 does.
>

That manpage you found online is in section 4x. It probably gets
installed along with the xf86-input-evdev package.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

freebsd-hackers mailing list
In reply to this post by Rodney W. Grimes-4


On 2019-Feb-17, at 18:35, Rodney W. Grimes <freebsd-rwg at pdx.rh.CN85.dnsmgr.net> wrote:

>> On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote:
>>>
>>>
>>> On 2019-Feb-17, at 10:03, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
>>>
>>> Anyone have insight into what evdev is?  There appears to
>>> be no manual page.  When I reboot a system with custom
>>> kernel, the system is autoloading evdev.ko, uhid.ko, and
>>> wmt.ko.  I do not need nor what these modules loaded.
>>> How does one prevent this autoloading?
>>>
>>> Looking via the web lead to:
>             ^^^^^^^^^^^^^^^
> web lies

The URL I listed (below) is to www.freebsd.org/cgi/man.cgi?query. . .
and I looked at the page's content before sending the message. That
is how I got the text that I quoted. (It is from section 4 "special
files".)

The freeBSD manpage servers might provide more man pages than are
installed?

>>>
>>> https://www.freebsd.org/cgi/man.cgi?query=evdev&apropos=0&sektion=4&manpath=FreeBSD+12.0-RELEASE&arch=default&format=html
>>> So:
>>>
>>> NAME
>>>       evdev - Generic Linux input driver
>>>
>>> DESCRIPTION
>>>
>>> evdev is an Xorg input driver for Linux's generic event devices. It
>>> therefore supports all input  devices  that  the kernel knows about,
>>> including most mice, keyboards, tablets and touchscreens. evdev
>>> is the default driver on the major Linux distributions.
>>> . . .
>>>
>>>
>>>
>>> but it seems to not have a 13-current entry. It does have
>>> a 12.0-RELEASE entry.
>>>
>>
>> Thanks.  Kinda odd that freebsd-current doesn't have a manual
>> page, but FreeBSD-12 does.
>
> rgrimes@t400:~ % man evdev
> No manual entry for evdev
> rgrimes@t400:~ % man -k evdev
> apropos: nothing appropriate
> rgrimes@t400:~ % uname -a
> FreeBSD t400.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE GENERIC  amd64
> rgrimes@t400:~ %
> There is no man page for evdev in 12.0-RELEASE
>
>>
>> I have a wireless logitech mouse.  It seems that the
>> wireless USB dongle is causing the load of the modules.
>> I still understand why as ums(4) does not should a
>> dependency on uhid, wmt, or evdev.
>



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Stefan Blachmann
In reply to this post by Steve Kargl
On 2/18/19, Vladimir Kondratyev <[hidden email]> 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...
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Johannes Lundberg

On 2/18/19 11:06 AM, Stefan Blachmann wrote:

> On 2/18/19, Vladimir Kondratyev <[hidden email]> 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?

Evdev with libinput provide things like, multitouch gestures, horizontal
scrolling, touchpad support, etc, i.e. functionality that one might
expect from a laptop or desktop computer newer than 10 years,  also for X11.

Having it enabled by default doesn't force you to use it but it makes it
a whole lot easier for all of those who want to use it. Please try to
consider what is the best middle ground for ALL users. If you have a
special application for FreeBSD you're probably building your own kernel
anyway and it is easy to disable if needed. Most normal (and especially
new to FreeBSD) desktop/laptop users use stock kernel and would benefit
from having access to this functionality.

Cheers

> 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...
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Niclas Zeising-6
In reply to this post by Stefan Blachmann
On 2/18/19 12:06 PM, Stefan Blachmann wrote:

> On 2/18/19, Vladimir Kondratyev <[hidden email]> 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.

Evdev and libinput is used by both Wayland and xorg.  You are free to
use either one.

Regards
--
Niclas Zeising
FreeBSD Graphics Team
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Baptiste Daroussin-2
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 <[hidden email]> 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.

Bapt

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Warner Losh
On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
[hidden email]> 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 <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Warner Losh
In reply to this post by Steve Kargl
On Sun, Feb 17, 2019 at 3:52 PM Steve Kargl <
[hidden email]> wrote:

> Anyone have insight into what evdev is?  There appears to
> be no manual page.  When I reboot a system with custom
> kernel, the system is autoloading evdev.ko, uhid.ko, and
> wmt.ko.  I do not need nor what these modules loaded.
> How does one prevent this autoloading?
>

Hi Steve,

This thread has taken a weird turn, so I went back to the original post.

When do these things get loaded? Is it when you start up X11? Or is it
being brought in by devmatch? If it is being brought in by x11, there's
likely an x11 config that you'll need to avoid them (but that will reduce
functionality). If it is devmatch, then you can add them to the black list
and have them not load them.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Steve Kargl
In reply to this post by Baptiste Daroussin-2
On Mon, Feb 18, 2019 at 04:56:57PM +0100, Baptiste Daroussin wrote:

> On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> >
> > 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.
>

And you seem to be missing the point.  I'm now in week two of
trying to figure out why drm-legacy-kmod no longer works, and
suddenly new devices are popping up which are not configured
in my kernel.

I have deleted all ports.  I have delete /usr/src and /usr/obj.
I used svn to pull a -r "{2019-01-01}" /usr/src.  That builds
and works fine.  I then build the minimum ports needs to install
drm-legacy-kmod and xorg.  I can fire a fvwm2 desktop.  I'm now
up to -r "{2019-01-28}".  Yes, bi-section be date.  It takes 6-7
hours to rebuild world and kernel and another hour or 2 for the
minimum set of ports.

PS: It still does answer why there isn't a manual page for evdev.

--
steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Ian Lepore-3
In reply to this post by Niclas Zeising-6
On Mon, 2019-02-18 at 08:50 -0800, Steve Kargl wrote:

> On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote:
> >
> > You do know these constant complaints about people trying to make
> > things
> > better is demoralizing and counter productive.
> >
>
> You do realize some of the emails are from frustrated users
> who are trying to make FreeBSD (see for example libm).  
>

And do you realize that you've trimmed away all the context so that now
it looks like Warner was talking to you, when in fact he was replying
to Rod? I sure hope that was an accident.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Steve Kargl
In reply to this post by Warner Losh
On Mon, Feb 18, 2019 at 09:35:26AM -0700, Warner Losh wrote:

> On Sun, Feb 17, 2019 at 3:52 PM Steve Kargl <
> [hidden email]> wrote:
>
> > Anyone have insight into what evdev is?  There appears to
> > be no manual page.  When I reboot a system with custom
> > kernel, the system is autoloading evdev.ko, uhid.ko, and
> > wmt.ko.  I do not need nor what these modules loaded.
> > How does one prevent this autoloading?
> >
>
>
> This thread has taken a weird turn, so I went back to the original post.
>
> When do these things get loaded? Is it when you start up X11? Or is it
> being brought in by devmatch? If it is being brought in by x11, there's
> likely an x11 config that you'll need to avoid them (but that will reduce
> functionality). If it is devmatch, then you can add them to the black list
> and have them not load them.
>

I think it is devmatch (or at least devd.conf related).
I have a wireless USB logitch mouse.  If I unplug the dongle
from its port and reboot, evdev.ko, uhid.ko, and wmt.ko do
not get loaded.  When I plug in the dongle, the 3 get loaded.
I can kldunload wmt and evdev, but as soon as the mouse is
moved both are reloaded.

ums(4) does not mention any of these devices as a requirement.
wmt(4) says it only works for touchscreen.  This laptop pre-dates
touchscreens, so loading the module is simply wasteful.  There
is no evdev(4), so can't determine what it is or does.

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Steve Kargl
In reply to this post by Ian Lepore-3
On Mon, Feb 18, 2019 at 09:58:14AM -0700, Ian Lepore wrote:

> On Mon, 2019-02-18 at 08:50 -0800, Steve Kargl wrote:
> > On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote:
> > >
> > > You do know these constant complaints about people trying to make
> > > things
> > > better is demoralizing and counter productive.
> > >
> >
> > You do realize some of the emails are from frustrated users
> > who are trying to make FreeBSD (see for example libm).  
> >
>
> And do you realize that you've trimmed away all the context so that now
> it looks like Warner was talking to you, when in fact he was replying
> to Rod? I sure hope that was an accident.
>

Thanks for your considered input.  It has been noted.

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Wojciech Puchar-8
In reply to this post by Steve Kargl
> motivated me to do this:
>
> 1) my observation that many developers at conferences and online were using
> macOS as their primary desktop environment.  when comparing this to the
> OpenBSD and Linux community I felt pretty embarrassed, but it did explain the
> stagnant nature of our graphics subsystem.  people seemed afraid to touch
> things due the brittle nature of its hardware support.
>
> 2) i was in need to an *affordable* machine with a warranty. fortunately
> there are many affordable laptops at staples, best-buy and amazon - but they
> were all post haswell systems, rendering them basically useless from a
> FreeBSD perspective.

I've bought recently (like half year ago) cheapest laptop available.
Everything supported with FreeBSD out of the box, except little problem
with sound but

dev.hdac.0.polling=1

made it work.

What a problem? Even lowest end today computer is really high end for
normal programs.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Michael Gmelin-3
In reply to this post by Warner Losh


> On 18. Feb 2019, at 23:54, Mark Linimon <[hidden email]> wrote:
>
>> On Mon, Feb 18, 2019 at 08:50:27AM -0800, Rodney W. Grimes wrote:
>> I think one serious problem here is the summary dismissal of things
>> simply on the "5 year old" basis.
>
> IIUC the graphics changes are being forced upon FreeBSD by external
> projects (mainly Linux-based) that are making huge architectural changes
> that rely more and more on features from newer hardware.
>
> If our upstreams aren't willing to do the work to keep from violating
> POLA on older hardware, IMHO it's an awful lot to ask of our already
> thinly stretched graphics volunteers to provide it in their stead.
>
> w/rt graphics, we are at far more danger of being left further and
> further behind on modern hardware than we are at risk of losing users
> on older hardware here.
>
> Again all IMHO.
>
> disclaimer: I don't use any fancy graphics stuff, so (as the old folks
> say around here)

I’m very happy (and grateful) that 2018 was the first year in over a decade I was able to run FreeBSD on a state of the art laptop with all the features that are essential to me working - which included decent touchpad support provided through evdev+libinput.

-m


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Warner Losh
In reply to this post by Warner Losh
On Mon, Feb 18, 2019 at 9:50 AM Rodney W. Grimes <
[hidden email]> wrote:

> > On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
> > [hidden email]> 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 <[hidden email]>
> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What is evdev and autoloading?

Warner Losh
In reply to this post by Niclas Zeising-6
On Mon, Feb 18, 2019 at 9:50 AM Steve Kargl <
[hidden email]> wrote:

> On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote:
> >
> > You do know these constant complaints about people trying to make things
> > better is demoralizing and counter productive.
> >
>
> You do realize some of the emails are from frustrated users
> who are trying to make FreeBSD (see for example libm).
>

Yes. I get that. My frustration isn't with you, or your questions. I get
why you want to run -current. I'm sorry it's being painful for you.
Sometimes, -current is like that.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
12