If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

If Or When Will X12 Actually Materialize?

Phoronix: If Or When Will X12 Actually Materialize?

The first version of the X protocol for the X Window System emerged in 1984 and just three years later we were at version 11. However, for the past 23 years, we have been stuck with X11 with no signs of the twelfth revision being in sight, even though there is a whole list of X12 plans and hopes on the FreeDesktop.org Wiki. Julien Danjou, an XCB developer, has written a lengthy blog post looking at the situation and the prospects for the X protocol...

The fundamental problem is that X11 works in 95% of cases and there are hacks for the vast majority of other cases (e.g. using NX to forward X11 connections over high-latency links); so no-one wants to rewrite all that manky Xlib code even if the new interface would be better.

Then there's the 'who wants to run graphics programs over a network anyway?' brigade who don't even see the benefits; which apparently includes KDE if their developers really think that running KDE apps over the network is a 'bizarre corner case'... that may explain why KDE apps crash so much when I run them on my Unix server with the display on my Windows laptop.

Is Zaphod mode really gone? Maybe there used to be more to it but I still use a setup where I have DISPLAY :0.0 and :0.1.

I too was thinking about something to improve the remote X situation. I love X11 forwarding over SSH but even with compression, it struggles when going beyond the LAN. I know of NX but something better integrated would be nice.

the problem with the windowing system -apart from the technical stuff which i cannot judge- seems to be that there is a total lack guidance/direction

noone seems to know -or to put it better decide- what we actually need

be it x11, x12 or wayland or something novel matters little

to me it seems that nobody wants or is able to make a decision on which direction things must move

well thats not entirely true, the xorg board is quite capable you know.

the problem here is more trivial than you think, is not a post apocaliptic war beetween projects or some dumb boys dont knowing what to do.

the problem core is the fact that X11 is 20ish years old and it need to be rewrited, that is a fact but the consequences are barbaric at the beggining.

let's see rigth now our favorite X guys are working hard to improve the FOSS driver stack, which btw is hellish hard. so is not like the have much free time for some months more. on the other hand rewrite the xorg core is much more complex than you think, rewrite the core of the xserver will sever the compatibility with everything outside bash. aka

* every gtk+/qt/kde/flux/enlighment/xfce/etc app will cease to work until properly patched + some revision later + some optimization later, aka maybe a year of hardwork

* every driver outhere for graphics/input/hid/mesa/ will cease to work too, on the foss side will probably take a month to basic render but fglrx and nvidia blobs will take ages (especially fglrx, i calculate 10 years to properly render in the new X)

* every commertial app will stop to work too, stuff like maya or catia + many scientific apps outhere

* wine would need a massive rewrite too

* kms probably would need a overhaul to add functions that make more sense to be in the kernel than the xorg

so, it's not like no one know what to do or anything like it, is more like they need to put thing togheter with other projects to focus in this new xorg xserver or the mess would be out of charts.

so in the end rewrite the xserver is a epicly massive effort that need focus on almost any project around that involve the use of the graphic system.

so for now they are just trying some clean ups here and there, but at the end a full rewrite will be needed cuz most of the xorg massive code is useless these days, and lets face it the rendering core was designed with the graphic capabilities of almost 30 years old card not for today smart multiGPU system with a chunk of vector cores and gigabytes of band in the pcie ports.

so xorg will be rewrite? yes, eventually. agood time could be after the foss driver get mature enough to keep it at least a year with only minor bugfixes, to let them focus entirely on create a new graphic/input system aka X12

the problem core is the fact that X11 is 20ish years old and it need to be rewrited, that is a fact but the consequences are barbaric at the beggining.

Agreed: it's rather like moving to IPV6; everyone knows we have to do it, but since a sudden switch would break the entire infrastructure, no-one wants to be first.

I guess that ideally you'd find a way to morph X11 to X12 by removing deprecated X11 functionality and adding the new X12 interfaces, but then no-one will bother to rewrite old code to use X12 because X11 still works. On the other hand, if you just throw away X11, no code will work.

One option would be to build an X11 to X12 translation layer so you could still run old X11 apps, but then you still have the problem of convincing people to port to X12 while X11 is still available.

That blog post was really good at explaining why we need toolkits for program design.

It would be really good to see wayland x11 gtk and qt folks all sitting down and coming up with a plan to rewrite and really simplify the stack.

Ideally you want the new x to be backward compatible but that would probably be to much work (and pointless). Instead maybe x11 could be rewritten to work as a virtual layer fallback for non compatible apps.

Then once the new x is properly defined there would be the less hassle in getting some of the userland converted.

IMO the biggest issue here is that most of the "problems with X11" we hear about have nothing to do with X itself, but in fact are related to other parts of the Linux graphics stack.

It's probably fair to say that X11 implements a number of functions which are not used today as a result of apps & toolkits making increased use of new APIs and direct rendering, which is presumably what drives the complaints about X being "bloated", but until substantially all of the user base is willing to deprecate all of the older X applications *and* give up a network-extensible API it's hard to argue that a change is even required. I don't think the problem is lack of leadership but more lack of a clearly defined problem.

Wayland is interesting because it implements a simple model for local, direct-rendered applications while continuing to support X for existing applications. Modern systems are capable of supporting a much richer style of interaction than X was designed for, and have less requirement for network-extensible graphics APIs -- so the Wayland approach seems to make a lot more sense than trying to turn X into something it was never intended to be.

@movieman: Even tge widgets of the plasma desktop are runnable over a network: KDE does care. Nokia expressed interest in making Qt Wayland compatible. Gtk+ was also interested or so I think I remember.

Maybe make X12 happen an create some Wine-ish Xlib emulatorish compatible extension? Something about mouse pointer positions and cut-pasting rendered bitmaps... Overhead but legacy compatibility only when it is required.

Pain in the ass, but the only way to progress.

However after all this restart this, reimplement that (Gallium), do we _want_ another action of invest in the future when that future gets choved and choved and choved again an again and again further into the future?