Yet another new Xserver

blackbird9

blackbird9

They're coming in thick and fast now... seems someone out there wants to keep X11 alive, thankfully.
www.theregister.com

Frame: A new X11 server – implemented directly in assembly

Joins yserver, Phoenix, and of course XLibre – and outlier Arcan
www.theregister.com www.theregister.com
The guy seems to like writing code in asm, or at least getting an AI to write asm for him. :-)
Also mentioned are yserver, phoenix and Xlibre. So that's 4 so far, and counting... 5 if you count Xorg.

Arcan gets a mention in the article too, I remember reading about that years ago.
arcan-fe.com

Arcan: 10 Years of Online Obscurity

… and 23 years of tedious yak shaving. Ten years ago my rather anemic post on the Arcan project started to circulate. It got enough attention that I considered stopping right there and …
arcan-fe.com arcan-fe.com
 
A bloat-free graphics screen would be nice. No display server, just a program that draws pixels on GPU-level at the speed of the GPU in a standardized way and runs from the non-graphical CLI.
 
MG said:
A bloat-free graphics screen would be nice. No display server, just a program that draws pixels on GPU-level at the speed of the GPU in a standardized way and runs from the non-graphical CLI.
Click to expand...
On linux there have been a couple of attempts... svgalib is the main one I know of https://svgalib.org/ I'm not sure whether there's something like that for freebsd.
 
Looks like there is an svgalib port for freebsd: graphics/svgalib .

And there is this freebsd implementation of webgpu https://github.com/awbradle/wgpu-freebsd , although perhaps that's not low-level enough, it's basically a superset of WebGL. Still, kind of interesting. They have C++ and Rust bindings. I wonder if it can be persuaded to write directly to the graphics card's framebuffer, without involving any kind of display server (or web app).
 
blackbird9 said:
On linux there have been a couple of attempts... svgalib is the main one I know of https://svgalib.org/ I'm not sure whether there's something like that for freebsd.
Click to expand...
The problem is that nVidia and Intel are against direct operation of graphics hardware and opetating systems don't like to admit that they just don't have the information for legal application.
These 2 should not be primary support target. We'll get to the point where computers can't display anything without branded software.
 
MG said:
The problem is that nVidia and Intel are against direct operation of graphics hardware and opetating systems don't like to admit that they just don't have the information for legal application.
These 2 should not be primary support target. We'll get to the point where computers can't display anything without branded software.
Click to expand...
It's tricky... not supporting those two architectures cuts you out of the majority of available hardware. At least when it was IBM, they used to publish the EGA and VGA programming specs so you knew how to program the hardware directly. I wonder what graphics hardware target the X server written in assembler was written for, I'm assuming he wrote all the low-level X stuff as well as the higher levels. Maybe he just used VESA. I guess VBE still works for VESA complient graphics adapters (whether or not they are in the cpu chipset) https://en.wikipedia.org/wiki/VESA_BIOS_Extensions . Or more likely he just pulled down the intel open source driver and integrated it with his stuff, or asked the AI to do it for him.
 
And I wonder if an AI that writes assembler is as good an assembly language programmer as an optimising C compiler, especially targeted at modern superscalar cpu's. Still, its interesting, and it's good that X11 is still getting some developer interest.
 
blackbird9 said:
And I wonder if an AI that writes assembler is as good an assembly language programmer as an optimising C compiler, especially targeted at modern superscalar cpu's. Still, its interesting, and it's good that X11 is still getting some developer interest.
Click to expand...
At 1 day this might become a new computer science theory if it doesn't already exist. The problem with AI generating assembly code that targets particular hardware is that the user has to describe what he wants in (I estimate) exactly the same level of detail that the acrtual development would involve. Unless the AI-system has some approveable grade and constructive skills..
 
blackbird9 said:
And I wonder if an AI that writes assembler is as good an assembly language programmer as an optimising C compiler, especially targeted at modern superscalar cpu's. Still, its interesting, and it's good that X11 is still getting some developer interest.
Click to expand...

Interesting question. I think LLMs are ready to understand Intel's optimization guide and generate (some) better machine code than the LLVM IR to machine can do. Not because the LLVM developers are dummies but because the framework for doing that work is too rigid. A LLM could also make more use of SIMD instructions.

The problem of course is the "some". There will be places where the LLM makes mistakes, and that won't make for a happy binary. Still, interesting question.
 
MG said:
A bloat-free graphics screen would be nice. No display server, just a program that draws pixels on GPU-level at the speed of the GPU in a standardized way and runs from the non-graphical CLI.
Click to expand...
Isn't that inherent in the definition of a compositor, or what wayland was suppose to be before the GNOME kronies got their fingers into it? I have nothing against the concept but see red and my blood starts boiling when they start dictating functional policy or hijacking the group to favor the agenda of a specific desktop/environment. I constantly see "security security security" as a reason for wayland. Well, their security breaks my workflow and lowers my productivity...but then I guess it's the same mentality as with company IT who treat systems designers as "administrative workers" where they cannot even manage their own PCs or customize their desktops.
 
6502 said:
Sounds interesting but is this compatible with Xserver or is something alternative?
Click to expand...
It appears to be a full X-server, like Xorg, since he says it implements the full X11 protocol; so it should be capable of replacing Xorg, and be backwards compatible. For it to be useful, you would want to be able to reliably run twm, xterm and xclock on it at the very least, and hopefully everything else besides.
 
mer said:
So if AI is writing the code, who do bugs get assigned to?
Click to expand...
Ah, that would be the 3-man 'slopfix' team... https://www.tomshardware.com/tech-i...k-to-delete-ai-generated-code-using-ai-agents
Yes, that really is their name... they charge a mere 10k a week (I wonder if we can set up an outfit like that?):-)

But I imagine the real answer is the guy who has developed it, with a little help from his AI buddy. It also makes me wonder how he tests and verifies the thing. He is going to test it before he ships it, right?
 
MG said:
At 1 day this might become a new computer science theory if it doesn't already exist. The problem with AI generating assembly code that targets particular hardware is that the user has to describe what he wants in (I estimate) exactly the same level of detail that the acrtual development would involve. Unless the AI-system has some approveable grade and constructive skills..
Click to expand...
Possibly, but that would seem to defeat the object of using an AI, if you have to describe it to the AI in as high a level of detail as actualy programming it yourself. It's kind of a strange choice for a target language for a relatively large project, compared to, say, C or something higher level; I wonder if using asm yields any real advantage at runtime over using a higher level target language.

Whereas if you wanted to optimise some small section of an existing project, say the code of an inner loop where you're spending 90% of your execution time and you need some help writing an optimised version of that in assembler, that seems a more reasonable thing to try to use an AI for. But I'm not going to pretend I know much about using LLM's to write asm.
 
kent_dorfman766 said:
Isn't that inherent in the definition of a compositor, or what wayland was suppose to be before the GNOME kronies got their fingers into it? I have nothing against the concept but see red and my blood starts boiling when they start dictating functional policy or hijacking the group to favor the agenda of a specific desktop/environment. I constantly see "security security security" as a reason for wayland. Well, their security breaks my workflow and lowers my productivity...but then I guess it's the same mentality as with company IT who treat systems designers as "administrative workers" where they cannot even manage their own PCs or customize their desktops.
Click to expand...
What they're talking about is that any particular X program on a display can sniff the input stream of other clients on the same display. So some hacked version of one client could be sniffing the password you type into your bank website in a browser on the same display. There is no inter-client isolation. Wayland claims to fix that. There's a summary here https://biggo.com/news/202511040138_X11-Wayland-Security-Debate . Quite how real a problem that is in practice, or what the relative risk is versus other classes of exploits, I don't know. The only truly secure computer is the one that has the power cable pulled out (and is not in the repair shop!)
 
MG said:
A bloat-free graphics screen would be nice. No display server, just a program that draws pixels on GPU-level at the speed of the GPU in a standardized way and runs from the non-graphical CLI.
Click to expand...
This is close to what I have been working on here:

https://research.thamessoftware.co.uk/glass/
https://gitlab.com/osen/openbsd_drmfb_gnuboy

For much of my uses, I generally do often skip the display server. Once libdrm (a pretty ugly API) had been abstracted, it feels like writing MS-DOS simulations using BGI, Watcom Drawing Primitives.

I did have plans to wrap the old FreeBSD specific vgl(3) API but frankly I like just setting pixels in a block of memory.
 
It's how we used to program graphics on micros, direct access to the frame buffer and graphics controller chip, single tasking. Which is kind of outside of the unix model, where everything you interact with is some kind of terminal, whether real hardware or virtual. I remember trying to program graphics on a vector graphics terminal on a vax when I was first learning unix and wishing it was as easy as drawing pictures on the bbc micro or speccy. It really stems from unix being a multi-user, multi-tasking operating system. MS-DOS was just another micro after all, single-tasking, single-user; you had full access to the machine, to do with whatever you wanted. Various graphics widgets in windowing systems give you a simulation of that, with a client area and a bunch of drawing primitves, but you don't own the whole machine. I guess DRI gives you a reserved piece of screen real estate mapped onto the framebuffer, that's about as close as you can get, in X anyway.
 
You must log in or register to reply here.
Back
Top