Date: Tue, 19 Feb 2019 18:59:26 +0000 From: Johannes Lundberg <johalun0@gmail.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Cc: freebsd-current@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: What is evdev and autoloading? Message-ID: <b5972449-4b83-6f9b-fc17-7d7309ff6461@gmail.com> In-Reply-To: <20190219173554.GA1066@troutmask.apl.washington.edu> References: <201902181650.x1IGoRsZ006131@pdx.rh.CN85.dnsmgr.net> <11a49d72-3158-1b9a-f933-6702d8f5c238@nomadlogic.org> <362D8283-0B7D-402F-99CD-657021597955@cschubert.com> <20190219173554.GA1066@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <pete@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. Por= t >>>> 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 usabl= e=20 >>> desktop environment on a modern laptop.=C2=A0 there were two issues w= hich=20 >>> motivated me to do this: >>> >>> 1) my observation that many developers at conferences and online were= =20 >>> using macOS as their primary desktop environment.=C2=A0 when comparin= g this=20 >>> to the OpenBSD and Linux community I felt pretty embarrassed, but it >>> did=20 >>> explain the stagnant nature of our graphics subsystem.=C2=A0 people s= eemed=20 >>> afraid to touch things due the brittle nature of its hardware support= =2E >> 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=20 >>> there are many affordable laptops at staples, best-buy and amazon - b= ut >>> >>> they were all post haswell systems, rendering them basically useless = >> >from a FreeBSD perspective. >> >> Which is why removing drm2 was necessary.=20 >> >>> after trying to get traction to update the in-tree drm subsystem i wa= s=20 >>> lucky enough to sync up with the graphics team which was working on=20 >>> syncing things up with modern hardware support.=C2=A0 because of that= i'm >>> now=20 >>> able to get my small startup pretty much all on board with FreeBSD.=C2= =A0 i=20 >>> use it on my workstations as well as on or server infrastructure=20 >>> (physical and AWS).=C2=A0 i would consider this a success for our com= munity=20 >>> 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.=C2=A0 how= many=20 >>> people are on haswell era hardware?=C2=A0 i can tell from my experien= ce the=20 >>> past several years the number of people who have post-haswell gear se= em >>> >>> to be more numerous, or at least more vocal (and frankly easier to wo= rk >>> >>> with while squashing bugs). >>> >>> i can also say that personally it would be great to improve support f= or >>> >>> 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.=20 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b5972449-4b83-6f9b-fc17-7d7309ff6461>