Ars Technica article

[Niclas Zeising]

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!
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.
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?  What 
direction change are you talking about?

Regards
-- 
Niclas Zeising
FreeBSD Graphics Team