Date: Mon, 13 Apr 2020 14:24:30 -0700 From: Chris <bsd-lists@BSDforge.com> To: Niclas Zeising <zeising@freebsd.org> Cc: FreeBSD X11 <x11@freebsd.org>, Alexey Dokuchaev <danfe@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: Ars Technica article Message-ID: <bc0649ab1abb16ab27813170f2559152@udns.ultimatedns.net> In-Reply-To: <037e5734-2642-57aa-c5de-aff78913d761@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <danfe@freebsd=2Eorg>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bc0649ab1abb16ab27813170f2559152>