What is evdev and autoloading?

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

Re: What is evdev and autoloading?

Johannes Lundberg

On 2/19/19 12:37 AM, Warner Losh wrote:

> 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.

When this happens, there's always vesa and scfb (software rendering) to
fall back to so your machine won't be rendered useless. Not saying this
should be the norm, but good to know so that your work get minimal
interruption. Alternatively, run experimental kernels/worlds in bhyve
(what I tend to do when I want everything accessible on the same local
machine).


>
> Warner
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> 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?

Cy Schubert-4
In reply to this post by Steve Kargl
On February 18, 2019 9:17:37 AM PST, Pete Wright <[hidden email]> wrote:

>
>
>On 2/18/19 8:50 AM, Rodney W. Grimes wrote:
>>> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
>>>
>>> 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 intree DRM2 that is in
>stable/12,
>> and some of whom have ventured into head/13 are having issues with
>thete a
>> "new" model (ie kmod broken by a base commit).  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.
>I've put a lot of effort helping test and document how to get a usable
>desktop environment on a modern laptop.  there were two issues which
>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.

I noticed this too. And every time it struck me as odd.

>
>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.

Which is why removing drm2 was necessary.

>
>after trying to get traction to update the in-tree drm subsystem i was
>lucky enough to sync up with the graphics team which was working on
>syncing things up with modern hardware support.  because of that i'm
>now
>able to get my small startup pretty much all on board with FreeBSD.  i
>use it on my workstations as well as on or server infrastructure
>(physical and AWS).  i would consider this a success for our community
>as it's opened up the eyes to a whole new generation of devs to
>FreeBSD.
>
>one thing missing from all of these arguments is real data.  how many
>people are on haswell era hardware?  i can tell from my experience the
>past several years the number of people who have post-haswell gear seem
>
>to be more numerous, or at least more vocal (and frankly easier to work
>
>with while squashing bugs).
>
>i can also say that personally it would be great to improve support for
>
>systems requiring drm2 - but that gear is hard to come by, so we are
>really dependent on helpful collaboration from those who are being
>effected.

Drm2 is not required. My current laptop is 5 years old, an HD3000. The previous one is 13 years old, i915. Both work perfectly with drm-current on 13-current. Franky, I don't see what the fuss is about.


>
>
>-pete
>
>--
>Pete Wright
>[hidden email]
>@nomadlogicLA
>
>_______________________________________________
>[hidden email] mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to
>"[hidden email]"

The only irritation with drm-current is after doing a NO_CLEAN build ARC is large enough that on occasion a video may not play because X is unable to get the memory. Other than that it works better than drm-legacy -- with no artifacts.

--
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX: <[hidden email]> Web: http://www.FreeBSD.org

        The need of the many outweighs the greed of the few.
_______________________________________________
[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?

Bernd Walter-4
In reply to this post by Niclas Zeising-6
On Mon, Feb 18, 2019 at 01:43:22PM +0100, Niclas Zeising 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.

I use it to run a wmt(4) touchpanel display, which wouldn't work otherwise.
I have to say that I kind of like the evdev system as it also makes it very
easy to place events from userland processes.
What I don't like is that we had no autosetup support in XOrg when I first
used it - in the meantime this might have changed however.

>
> 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-current
> To unsubscribe, send any mail to "[hidden email]"

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[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 Cy Schubert-4
On Tue, Feb 19, 2019 at 08:17:48AM -0800, Cy Schubert wrote:

> On February 18, 2019 9:17:37 AM PST, Pete Wright <[hidden email]> wrote:
> >
> >
> >On 2/18/19 8:50 AM, Rodney W. Grimes wrote:
> >>> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
> >>>
> >>> 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 intree DRM2 that is in
> >stable/12,
> >> and some of whom have ventured into head/13 are having issues with
> >thete a
> >> "new" model (ie kmod broken by a base commit).  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.
> >I've put a lot of effort helping test and document how to get a usable
> >desktop environment on a modern laptop.  there were two issues which
> >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.
>
> I noticed this too. And every time it struck me as odd.
>
> >
> >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.
>
> Which is why removing drm2 was necessary.
>
> >
> >after trying to get traction to update the in-tree drm subsystem i was
> >lucky enough to sync up with the graphics team which was working on
> >syncing things up with modern hardware support.  because of that i'm
> >now
> >able to get my small startup pretty much all on board with FreeBSD.  i
> >use it on my workstations as well as on or server infrastructure
> >(physical and AWS).  i would consider this a success for our community
> >as it's opened up the eyes to a whole new generation of devs to
> >FreeBSD.
> >
> >one thing missing from all of these arguments is real data.  how many
> >people are on haswell era hardware?  i can tell from my experience the
> >past several years the number of people who have post-haswell gear seem
> >
> >to be more numerous, or at least more vocal (and frankly easier to work
> >
> >with while squashing bugs).
> >
> >i can also say that personally it would be great to improve support for
> >
> >systems requiring drm2 - but that gear is hard to come by, so we are
> >really dependent on helpful collaboration from those who are being
> >effected.
>
> Drm2 is not required. My current laptop is 5 years old, an HD3000. The previous one is 13 years old, i915. Both work perfectly with drm-current on 13-current. Franky, I don't see what the fuss is about.
>
>

My Dell Latitude D530 running i386 freebsd, which used the
i915kms.ko now locks up solid with drm-legacy-kmod.  The PAE vs
non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod.
It seems that Niclas has provided a patch that fixes the building
of drm-legacy-kmod.

Doing a bisection on /usr/src commits is fairly slow as it
takes a day to build world/kernel and the minimum set of ports
need to fire up Xorg.  r343543 and earlier appear to work fine
with drm-legacy-kmod.

I have now lost 2 weeks of hacking time that could have been spent
on the missing C99 complex math routines.  Yeah, I know very few
people care about numerical simulations on FreeBSD.

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

Johannes Lundberg

On 2/19/19 5:35 PM, Steve Kargl wrote:

> On Tue, Feb 19, 2019 at 08:17:48AM -0800, Cy Schubert wrote:
>> On February 18, 2019 9:17:37 AM PST, Pete Wright <[hidden email]> wrote:
>>>
>>> On 2/18/19 8:50 AM, Rodney W. Grimes wrote:
>>>>> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
>>>>>
>>>>> 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 intree DRM2 that is in
>>> stable/12,
>>>> and some of whom have ventured into head/13 are having issues with
>>> thete a
>>>> "new" model (ie kmod broken by a base commit).  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.
>>> I've put a lot of effort helping test and document how to get a usable
>>> desktop environment on a modern laptop.  there were two issues which
>>> 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.
>> I noticed this too. And every time it struck me as odd.
>>
>>> 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.
>>
>> Which is why removing drm2 was necessary.
>>
>>> after trying to get traction to update the in-tree drm subsystem i was
>>> lucky enough to sync up with the graphics team which was working on
>>> syncing things up with modern hardware support.  because of that i'm
>>> now
>>> able to get my small startup pretty much all on board with FreeBSD.  i
>>> use it on my workstations as well as on or server infrastructure
>>> (physical and AWS).  i would consider this a success for our community
>>> as it's opened up the eyes to a whole new generation of devs to
>>> FreeBSD.
>>>
>>> one thing missing from all of these arguments is real data.  how many
>>> people are on haswell era hardware?  i can tell from my experience the
>>> past several years the number of people who have post-haswell gear seem
>>>
>>> to be more numerous, or at least more vocal (and frankly easier to work
>>>
>>> with while squashing bugs).
>>>
>>> i can also say that personally it would be great to improve support for
>>>
>>> systems requiring drm2 - but that gear is hard to come by, so we are
>>> really dependent on helpful collaboration from those who are being
>>> effected.
>> Drm2 is not required. My current laptop is 5 years old, an HD3000. The previous one is 13 years old, i915. Both work perfectly with drm-current on 13-current. Franky, I don't see what the fuss is about.
>>
>>
> My Dell Latitude D530 running i386 freebsd, which used the
> i915kms.ko now locks up solid with drm-legacy-kmod.  The PAE vs
> non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod.
> It seems that Niclas has provided a patch that fixes the building
> of drm-legacy-kmod.
>
> Doing a bisection on /usr/src commits is fairly slow as it
> takes a day to build world/kernel and the minimum set of ports
> need to fire up Xorg.  r343543 and earlier appear to work fine
> with drm-legacy-kmod.

So it's not only a build error, it's also a runtime bug that would have
happened even with drm2 in base? Hmm..

>
> I have now lost 2 weeks of hacking time that could have been spent
> on the missing C99 complex math routines.

Yeah it sucks when you have to get your hands dirty and actually
contribute yourself to keep the code you use alive and no one else does
it for you... How many hours do you think we have lost dealing with all
the whining and complaining on the mailing list where we instead could
have done productive work?

>   Yeah, I know very few
> people care about numerical simulations on FreeBSD.
>

_______________________________________________
[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 Tue, Feb 19, 2019 at 06:59:26PM +0000, Johannes Lundberg wrote:

>
> On 2/19/19 5:35 PM, Steve Kargl wrote:
>> On Tue, Feb 19, 2019 at 08:17:48AM -0800, Cy Schubert wrote:
>>>
>>> Drm2 is not required. My current laptop is 5 years old, an HD3000. The previous one is 13 years old, i915. Both work perfectly with drm-current on 13-current. Franky, I don't see what the fuss is about.
>>>
>>>
>> My Dell Latitude D530 running i386 freebsd, which used the
>> i915kms.ko now locks up solid with drm-legacy-kmod.  The PAE vs
>> non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod.
>> It seems that Niclas has provided a patch that fixes the building
>> of drm-legacy-kmod.
>>
>> Doing a bisection on /usr/src commits is fairly slow as it
>> takes a day to build world/kernel and the minimum set of ports
>> need to fire up Xorg.  r343543 and earlier appear to work fine
>> with drm-legacy-kmod.
>
> So it's not only a build error, it's also a runtime bug that would have
> happened even with drm2 in base? Hmm..

It appears that that's the case.  The likely candidates
are r343564(+65 for missing header), r343566, and r343567.

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

Tijl Coosemans
On Tue, 19 Feb 2019 11:18:07 -0800 Steve Kargl
<[hidden email]> wrote:

> On Tue, Feb 19, 2019 at 06:59:26PM +0000, Johannes Lundberg wrote:
>> On 2/19/19 5:35 PM, Steve Kargl wrote:  
>>> My Dell Latitude D530 running i386 freebsd, which used the
>>> i915kms.ko now locks up solid with drm-legacy-kmod.  The PAE vs
>>> non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod.
>>> It seems that Niclas has provided a patch that fixes the building
>>> of drm-legacy-kmod.
>>>
>>> Doing a bisection on /usr/src commits is fairly slow as it
>>> takes a day to build world/kernel and the minimum set of ports
>>> need to fire up Xorg.  r343543 and earlier appear to work fine
>>> with drm-legacy-kmod.  
>>
>> So it's not only a build error, it's also a runtime bug that would have
>> happened even with drm2 in base? Hmm..  
>
> It appears that that's the case.  The likely candidates
> are r343564(+65 for missing header), r343566, and r343567.

That last commit added hw.above4g_allow tunable.  Does it help if you
set this to 0 in /boot/loader.conf?

Also, it's worth trying drm-current-kmod if you haven't done so
recently.  If you did try already what were the problems?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
12