What is evdev and autoloading?
Steve Kargl
sgk at troutmask.apl.washington.edu
Tue Feb 19 17:36:07 UTC 2019
On Tue, Feb 19, 2019 at 08:17:48AM -0800, Cy Schubert wrote:
> On February 18, 2019 9:17:37 AM PST, Pete Wright <pete at nomadlogic.org> 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
More information about the freebsd-hackers
mailing list