From owner-freebsd-x11@freebsd.org Mon Apr 13 21:23:58 2020 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 112362A997B for ; Mon, 13 Apr 2020 21:23:58 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 491M7K4Vnbz4Dwf for ; Mon, 13 Apr 2020 21:23:57 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: by mailman.nyi.freebsd.org (Postfix) id 98C2E2A9978; Mon, 13 Apr 2020 21:23:57 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 988412A9977 for ; Mon, 13 Apr 2020 21:23:57 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 491M7J5pFfz4Dwc; Mon, 13 Apr 2020 21:23:56 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 03DLOOq6087588 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Apr 2020 14:24:30 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: FreeBSD X11 , Alexey Dokuchaev , Warner Losh In-Reply-To: <037e5734-2642-57aa-c5de-aff78913d761@freebsd.org> From: Chris Reply-To: bsd-lists@BSDforge.com To: Niclas Zeising Subject: Re: Ars Technica article Date: Mon, 13 Apr 2020 14:24:30 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 491M7J5pFfz4Dwc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.60 / 15.00]; NEURAL_HAM_MEDIUM(-0.89)[-0.893,0]; NEURAL_HAM_LONG(-0.71)[-0.709,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 21:23:58 -0000 On Mon, 13 Apr 2020 12:29:51 +0200 Niclas Zeising zeising@freebsd=2Eorg said > On 2020-04-13 11:14, Chris wrote: > > On Mon, 13 Apr 2020 01:11:30 -0600 Warner Losh imp@bsdimp=2Ecom said > >=20 > >> On Sun, Apr 12, 2020, 11:24 PM Alexey Dokuchaev =20 > >> wrote: > >> > >> > [ setting CC to a more appropriate -x11@ list ] > >> > > >> > On Sat, Apr 11, 2020 at 12:43:00AM +0000, Niclas Zeising wrote: > > =2E=2E=2Ebig snip=2E=2E=2E > >> in this part of the stack: the drm-kmod maintainer's job shifted so he= 's > >> had to resign from that role=2E We have nobody to even update to newer= =20 > >> Linux > >> driver versions (though we might have a promising person in the wings)= =2E > >> There's literally nobody that has the time, the hardware, the docs and= =20 > >> the > >> expertise to help with this older video hardware (at least as evidence= of > >> it's remaining broken for a long, long time)=2E Until that person shows = up, > >> you will unfortunately be out of luck=2E > >=20 > > OK I've bit my tongue as long as I can on this=2E=2E=2E > > How is importing yet more Linux code into FreeBSD a better thing? Or ho= w > > is it *fixing* anything regarding FreeBSD=2E For clarity; I don't dislike > > Linux=2E I just prefer to use (Free)BSD=2E I'm frankly alarmed with the=20 > > apparent > > volume that Linux code is entering the FreeBSD code base=2E I noticed muc= h of > > the UEFI bits are also converted Linux bits=2E I suppose for a quick need= ed > > stop-gap solution it might be reasonable=2E But it appears that a tremend= ous > > amount of time, and effort has gone into all this, and given the previo= usly > > mentioned lack of man-power=2E It seems unlikely that any of this will be > > replaced with a FreeBSD equivalent=2E I'm not blowing smoke here=2E I earma= rked > > some time that I wouldn't be taking contracts so that I could invest so= me > > time on FreeBSD concerning "nits" I had that I thought could improve th= ings > > a bit=2E I looked into taking the time to make it nearly/fully POSIX=20 > > complaint=2E > > Browsing the code=2E It was clear I wouldn't stand a chance unless I star= ted > > at ~9=2Ex where it starts to go sideways in fairly rapid succession=2E So I > > decided to look elsewhere=2E I've had some nits with the Graphics dept=2E s= o > > I thought I'd look to see where I could best spend my efforts=2E Then the= new > > Xorg landed=2E Well that's going a *completely* different direction than = it > > was, and I don't think I want to participate in that new direction=2E > > I've finally landed on working on bolstering sc/syscons in an effort to > > provide graphics mode switching and detection to it=2E > >=20 > > Sorry if I've usurped this thread=2E But it's really been bothering me, > > and I think others=2E So I just said it=2E > >=20 >=20 > Hi! Hi! First off, I want you to know I'm *extremely* grateful for all your time and dedication, Niclas=2E Thank you! > I can only answer for the graphics parts, nothing else=2E > The short answer is, we need the linux code=2E Developing a graphics=20 > driver from scratch, let alone 2 or 3, is an enormous effort, requiring= =20 > a lot of time and manpower, resources we don't have=2E Writing and=20 > extending a compat layer (lkpi) to be able to compile and run the linux= =20 > drivers with as little effort as possible was the only way to do it, and= =20 > this also has given us a chance to keep them updated=2E Understood=2E=2E=2E > Remember that there was a previous effort, the one today called=20 > drm-legacy-kmod, to port the linux drivers to FreeBSD without using=20 > lkpi=2E While this effort was somewhat successful, it was not possible to= =20 > keep it going and keep it up to date with the resources we have=2E >=20 > I'm not sure what you're referring to with "the new Xorg" and the change= =20 > of direction=2E Are you referring to the update of xserver to 1=2E20? Yes=2E Most of the changes I was referring to landed along with 1=2E20=2E The UE was a disappointment=2E You're personal support was priceless=2E But if I had been given the where-with-all to do-with-all from the start=2E I wouldn't have had to ask for help, and you would have had more time to code, spending less time *supporting* your work=2E :) IOW IMHO more information should have been created, and pointed to before the large change(s) landed=2E > What=20 > direction change are you talking about? As alluded to earlier; the importation of so much Linux code=2E On one hand; yes it shortens the time-to-implementation=2E But in the broader scope; it's more work (and time) in the long term for it's removal, and replacement -- assuming that day ever arrives=2E The Kpi is also a kludge, and with it comes a performance hit=2E Is there really that little interest in the Graphics area/dept=2E that what we've currently been using couldn't be sustained/improved? >=20 > Regards > --=20 > Niclas Zeising > FreeBSD Graphics Team Thank you very much for the thoughtful, and informative reply, Niclas! --Chris -- UNIX is like Ice Cream=2E It comes in several flavors=2E But in the end, it's still Ice Cream=2E