undefined | Better HN

0 pointsvidarh4y ago0 comments

> Mid 80s hardware, actually.

I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :)

> WHAT IS YOUR ROOT?

A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though.

The X protocol is messy in places, but Xlib is far worse than necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value.

So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better.

There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach.

In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients.

EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.

0 comments

4 comments · 1 top-level

DonHopkins4y ago· 3 in thread

The problem with pure reimplementations of XLib in other languages is that there's no way they can use the client side X extension libraries that are based on XLib.

I learned that the hard way when trying to figure out how to use Display PostScript with CLX in 1992, which is an X client library written in Common Lisp.

https://www.cliki.net/clx

Few people still write applications directly to XLib, but many do write applications directly to toolkits and libraries that DO depend on XLib.

So we're all stuck with XLib from now until eternity. If you replace it, you lose the entire ecosystem of client side extension libraries, so you have to reimplement them all from scratch.

At the time, that was a no-go if you wanted to use Adobe's proprietary Display PostScript extension, which was quite popular and included with most commercial X11 servers of the era. Even if most important X extensions are open source, how about about them NVIDIA drivers?

Display PostScript is simply an old example from 1992 of what I mean, that I wanted to use from Common Lisp via CLX, but couldn't. But it shows how this problem has been around for a long time, and is never going away. The only viable solution was to dump CLX and call XLib and the Display PostScript extension libraries directly from Lisp through a wrapper layer.

But now the problem with clients and toolkits depending on X11 extensions is much more entrenched, not just limited to high-end exotic graphics-rich apps that want to use Display PostScript to draw a nice pie chart.

That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries -- just to measure the display, shape windows, listen for input, memory map pixmaps, and composite the first pixel on the screen -- because they've long since abandoned X11's horrible old built-in pixel-based rendering API, broken font model, leaky input system, etc, and switched to using full stacks of X11 extensions (via their XLib based libraries) instead.

yjftsjthsd-h4y ago

> That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries

Then Wayland will be more a nightmare still, since they moved everything but core rendering into extensions and say "just use wlroots" to deal with it.

md8z4y ago

No, you have it mixed up. Wlroots is on the server, the Xlib problem is explicitly with client libraries.

vidarhOP4y ago

Absolutely agree that a general purpose replacement for Xlib would be a massive pain, but providing sufficient support for the core protocol to let you add whichever request types you need is quite simple (and I lifted that from a decade old starting point and made it work).

And for my use I only need to support about a dozen requests types, and no third party libs, so it's not that bad. My starting point only linked with Xlib anyway, nothing else, and I verified which requests Xlib actually sent via xtruss before I started.

But of course, that's because I only want to actually use it for something very simple. If I wanted to do something more complex I'd wrap a higher level library instead.

j / k navigate · click thread line to collapse