Announcement

Collapse
No announcement yet.

If Or When Will X12 Actually Materialize?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    http://www.phoronix.com/vr.php?view=ODMwOA

  • #2
    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.

    Comment


    • #3
      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

      Comment


      • #4
        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.

        Comment


        • #5
          Originally posted by 89c51 View Post
          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

          * 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

          Comment


          • #6
            Originally posted by jrch2k8 View Post
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  Hey Michael, this should have become an article!

                  @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?

                  Comment


                  • #10
                    Originally posted by jrch2k8 View Post
                    well thats not entirely true, the xorg board is quite capable you know.
                    i didn't meant anything bad about the coding abilities of the xorg people

                    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?????

                    Comment


                    • #11
                      I can't really see how anyone can still talk about a possible success of wayland! It's dead! Its repository didn't see any change since march: http://cgit.freedesktop.org/~krh/wayland

                      Don't misunderstand me, if the project comes back to life, I'll be very happy, but at the moment there's nothing that can suggest that's going to happen.

                      Comment


                      • #12
                        Originally posted by jrch2k8 View Post
                        rewrite the core of the xserver will sever the compatibility with everything outside bash. aka

                        * [enumeration of how the world as we know it will cease to exist]
                        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.

                        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.

                        Comment


                        • #13
                          Maybe this is waaaaaaaaaaay off, but is it possible make a functionality parser and replace step by step?

                          For example:
                          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.

                          Comment


                          • #14
                            PS: have this parser act as the legacy mode for parsing to X11 for older apps

                            Comment


                            • #15
                              Originally posted by bridgman View Post
                              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
                              This is true as far as it goes, but I don't understand why some people are so eager to throw out the network element. I don't think a lot of effort should necessarily go into direct support for networks, but it seems like the requirements for a stable long-lived protocol and a network-transparent protocol overlap a lot. Even among individual machines, there's a pretty wide range of "distances" between the graphics hardware and the host processor. Network transparency seems like a natural extension to supporting that range.

                              Originally posted by phtpht
                              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.
                              As I understand it, the main desire behind Wayland was to have a simple playground for testing various techniques with the new Linux graphics stack (KMS/DRI2). I'm pretty sure it's meant to complement Xorg, not replace it.

                              Comment

                              Working...
                              X