Ars Technica article

[Chris]

On Mon, 13 Apr 2020 12:29:51 +0200 Niclas Zeising zeising at freebsd.org said

> On 2020-04-13 11:14, Chris wrote:
> > On Mon, 13 Apr 2020 01:11:30 -0600 Warner Losh imp at bsdimp.com said
> > 
> >> On Sun, Apr 12, 2020, 11:24 PM Alexey Dokuchaev <danfe at freebsd.org> 
> >> wrote:
> >>
> >> > [ setting CC to a more appropriate -x11@ list ]
> >> >
> >> > On Sat, Apr 11, 2020 at 12:43:00AM +0000, Niclas Zeising wrote:
> > ...big snip...
> >> in this part of the stack: the drm-kmod maintainer's job shifted so he's
> >> had to resign from that role. We have nobody to even update to newer 
> >> Linux
> >> driver versions (though we might have a promising person in the wings).
> >> There's literally nobody that has the time, the hardware, the docs and 
> >> the
> >> expertise to help with this older video hardware (at least as evidence of
> >> it's remaining broken for a long, long time). Until that person shows up,
> >> you will unfortunately be out of luck.
> > 
> > OK I've bit my tongue as long as I can on this...
> > How is importing yet more Linux code into FreeBSD a better thing? Or how
> > is it *fixing* anything regarding FreeBSD. For clarity; I don't dislike
> > Linux. I just prefer to use (Free)BSD. I'm frankly alarmed with the 
> > apparent
> > volume that Linux code is entering the FreeBSD code base. I noticed much of
> > the UEFI bits are also converted Linux bits. I suppose for a quick needed
> > stop-gap solution it might be reasonable. But it appears that a tremendous
> > amount of time, and effort has gone into all this, and given the previously
> > mentioned lack of man-power. It seems unlikely that any of this will be
> > replaced with a FreeBSD equivalent. I'm not blowing smoke here. I earmarked
> > some time that I wouldn't be taking contracts so that I could invest some
> > time on FreeBSD concerning "nits" I had that I thought could improve things
> > a bit. I looked into taking the time to make it nearly/fully POSIX 
> > complaint.
> > Browsing the code. It was clear I wouldn't stand a chance unless I started
> > at ~9.x where it starts to go sideways in fairly rapid succession. So I
> > decided to look elsewhere. I've had some nits with the Graphics dept. so
> > I thought I'd look to see where I could best spend my efforts. Then the new
> > Xorg landed. Well that's going a *completely* different direction than it
> > was, and I don't think I want to participate in that new direction.
> > I've finally landed on working on bolstering sc/syscons in an effort to
> > provide graphics mode switching and detection to it.
> > 
> > Sorry if I've usurped this thread. But it's really been bothering me,
> > and I think others. So I just said it.
> > 
> 
> Hi!
Hi!
First off, I want you to know I'm *extremely* grateful for all your time
and dedication, Niclas. Thank you!
> I can only answer for the graphics parts, nothing else.
> The short answer is, we need the linux code.  Developing a graphics 
> driver from scratch, let alone 2 or 3, is an enormous effort, requiring 
> a lot of time and manpower, resources we don't have.  Writing and 
> extending a compat layer (lkpi) to be able to compile and run the linux 
> drivers with as little effort as possible was the only way to do it, and 
> this also has given us a chance to keep them updated.
Understood...
> Remember that there was a previous effort, the one today called 
> drm-legacy-kmod, to port the linux drivers to FreeBSD without using 
> lkpi.  While this effort was somewhat successful, it was not possible to 
> keep it going and keep it up to date with the resources we have.
> 
> I'm not sure what you're referring to with "the new Xorg" and the change 
> of direction.  Are you referring to the update of xserver to 1.20?
Yes. Most of the changes I was referring to landed along with 1.20.
The UE was a disappointment. You're personal support was priceless. But
if I had been given the where-with-all to do-with-all from the start. I
wouldn't have had to ask for help, and you would have had more time to
code, spending less time *supporting* your work. :) IOW IMHO more
information should have been created, and pointed to before the large
change(s) landed.
>  What 
> direction change are you talking about?
As alluded to earlier; the importation of so much Linux code. On one
hand; yes it shortens the time-to-implementation. 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.
The Kpi is also a kludge, and with it comes a performance hit.
Is there really that little interest in the Graphics area/dept. that
what we've currently been using couldn't be sustained/improved?

> 
> Regards
> -- 
> Niclas Zeising
> FreeBSD Graphics Team
Thank you very much for the thoughtful, and informative reply, Niclas!

--Chris

--
UNIX is like Ice Cream. It comes in several flavors.
But in the end, it's still Ice Cream.