NetBSD graphics stack [WAS: Re: Internet services and US vs EU jurisdiction]

["Enrico Weigelt, metux IT consult" <info%metux.net@localhost>]

On 1/20/26 15:02, tlaronde%kergis.com@localhost wrote:

> On this, we agree. I tried to tackle the DRM problem (without having
> any knowledge at first) and after several tries and false starts only
> concluded:

By "DRM" you mean direct rendering manager or digital restriction 
management ?

> 1) That X11 is dead; 

https://github.com/X11Libre

NetBSD is one of our official CI targets, btw.
(we could use some more hands on deck, especially for testing,
packaging, etc)

> 2) That the way the GPUs are currently
> handled is out of reach of a small group with limited time and that
> in this area only Linux will survive. 

Why so ?

Yes, NetBSD still quite a bunch of work to be done for keeping up
(especially on kernel side), but most of the required prior work is
already there in one or another form.

By the way, if anybody here likes to do some serious work on NetBSD
graphics/gpu stack, just let me know. I might have some pieces to add
here (btw, I happen to be that linux kernel maintainer, who's banned
on vger.kernel.org's mail systems ;-)).

Option a) reimplement the Linux's /dev/dri/* interface as-is.
-> pro: easy compatibility with existing things above (mesa, X, ...)
-> con: has to carry certain Linuxims that might not be wanted

Option b) invent something new
-> pro: no need to redo Linux's mistakes (eg. I'd prefer all userland-
   accessible objects by identified by fd's, instead of magic cookies)
-> con: more work to do, especially in userland

Not matter what, we - the Xlibre team - will be happy to join in here
and do our part on X side.

> I'm now
> working on building a simple alternative for the 2D rendering, and
> I'm now trying to master a kernel so that I will not depend indirectly
> on the way the massive organisations are pushing the trend.

Oh, can you tell us some more ?

I'm still interested in a sane way to do 2D accelaration support via
some generic kernel interface, that doesn't require complex userspace
stuff (like we eg. have in xf86-video-* drivers) and more importantly
can be done fully unprivileged (similar to what DRI can already do
on 3D GPUs). That would also be interesting for small embedded SoCs
having certain 2D acceleration (even if it's just simple SDMACs), but
no modern (eg GLES-capable) 3D support.

> So, yes, having alternatives for OSes. And still being able to place
> physical systems (not only "online" servers). And to have alternative
> ways to connect and having even UUCP as a fallback.

Oh, UUCP. Somebody who still knows it :)

Have I ever mentioned that decades ago (before we had DSL flatrates,
but instead ways to make extremely short ISDN data calls for free)
I've done http proxy syncs (heavily patched up wwwoffle) as well as
async DB miroring (yes, two-ways :p) via UUCP ?

Even today, even when one's (almost) always connected, UUCP is still
a great tool for any kind of queued data transfers. Maybe we should
build up some fance high-gloss marketing papers and sell that to some
big corps as the next great shit, eg. for outer space transmissions
(it's old enough that most people already forgot about it) ;-)

> I still believe that "small is beautiful" because it will remain the
> simplest way to achieve minimal dependencies.

Indeed.


--mtx

--
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info%metux.net@localhost -- +49-151-27565287