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.
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.
Originally Posted by 89c51
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
* forget about java, flash, web browsers, google goddies, graphic bindings in python, perl, ruby, etc, no more mono for a while.
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
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.
Originally Posted by jrch2k8
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.
i didn't meant anything bad about the coding abilities of the xorg people
Originally Posted by jrch2k8
the post was just how i feel/think the situation is
nothing more than an opinion and for sure wrong in many things
however what i would like to see as someone mentioned above is all the desktop people (gnome kde enlightenment xorg etc) seat down and deside where things should head (x12 wayland with x11 on top etc)
also a question
i remember Kristian Høgsberg writing something about GTK being easy (whatever that means) to wayland after the gtk people have impleented client side windows
anyone knows whats this all about and also how "easy" is to port other toolkits to wayland?????
Obviously noone wants to do this. This is the grand-rewrite way of the 90s. In 2010 we already know better. We know that this way brings N years of concentrated effort in the grand rewrite itself and 4*N years of suffering afterwards. By the time it's finished it's already old.
Originally Posted by jrch2k8
Improvements must come incrementally.
Thus: Pick one small problem in the X lib/X protocol/whatever. Write a fix. If it conflicts with something, develop it as an independent functionality. Then start migrating old clients to new functionality. Eventually outcast the old code to some 'compatibility mode' or drop it altogether. Rinse and repeat.
When the 'compat' code starts being a serious pain, outcast it even further. Change the name to X12 and put the 'compat' code in a X11 emulator for X12.
BTW. Stupidly enough the Wayland project seems to go the grand way. It will be a miracle if it manages to take off, let alone replacing X.
Maybe this is waaaaaaaaaaay off, but is it possible make a functionality parser and replace step by step?
The parser is a yes man app, it says: "Yeah yeah yeah, I am X11... now give me your commands" and parses it to X11 as if nothing happened.
Then slowly but surely build up X12 sideways with this system in mind.
Slowly but surely, whenever some X12 feature is completed, hack and slash up the X11 feature to make it compatible with accepting that X12 feature output and slowly but surely replace everything until X12 can run on its own, individualy.
Everytime a feature is replaced, fix whatever there could be fixed in every major FLOSS app that is affected by this different behavior. Keep a schedule that is on par with the Xn (see what I did there?) schedule and maintain this list that predicts how certain apps will be affected every 6 months so people can see problems way in advance and are able to adjust their project planning slightly everytime. Do it in such a way that each time a new X12 feature is in place during a X.org release, postpone it's activation untill the next release comes around. This should give FLOSS app devs a minimum of 6 months at any given time to plan ahead.
When X13 would come around this parsing system could instantly be put in place to do the same with X12 without effort.
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.