Re: What is evdev and autoloading?

From: Cy Schubert <>
Date: Tue, 19 Feb 2019 10:47:08 -0800
On February 19, 2019 9:35:54 AM PST, 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
><> 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
>> >year
>> >> old hardware that are totally happy with the intree DRM2 that is
>> >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
>> >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. 
>> >> 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
>> >> simply on the "5 year old" basis.  Not everyone, and infact few
>> >> 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
>> >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
>> >using macOS as their primary desktop environment.  when comparing
>> >to the OpenBSD and Linux community I felt pretty embarrassed, but it
>> >did 
>> >explain the stagnant nature of our graphics subsystem.  people
>> >afraid to touch things due the brittle nature of its hardware
>> 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 -
>> >
>> >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
>> >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. 
>> >use it on my workstations as well as on or server infrastructure 
>> >(physical and AWS).  i would consider this a success for our
>> >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
>> >people are on haswell era hardware?  i can tell from my experience
>> >past several years the number of people who have post-haswell gear
>> >
>> >to be more numerous, or at least more vocal (and frankly easier to
>> >
>> >with while squashing bugs).
>> >
>> >i can also say that personally it would be great to improve support
>> >
>> >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.
Cy Schubert <>
FreeBSD UNIX: <> Web:

	The need of the many outweighs the greed of the few.
Received on Tue Feb 19 2019 - 18:06:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC