What is evdev and autoloading?

Cy Schubert Cy.Schubert at cschubert.com
Tue Feb 19 19:06:58 UTC 2019


On February 19, 2019 9:35:54 AM PST, Steve Kargl <sgk at troutmask.apl.washington.edu> 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
><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. 

Going down an unexpected rabbit hole is frustrating.

-- 
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.


More information about the freebsd-current mailing list