Re: What is evdev and autoloading?

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