Announcement

Collapse
No announcement yet.

X.Org Server Development Process Is Questioned

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

  • #16
    Originally posted by curaga View Post
    Then they'd be stuck with the inferior solution in kernel forever.
    Yuuuuuuuuuup. Remember, kernel policy is anything that ever hits mainline that userspace can use can never break. Ever. If someone wants to run a motif app from 1995 that was designed around kernel 2.4.12 (im picking a random release number there lol), that app has to work as far as the kernel is concerned. It can break because of userspace changes, thats fine, but if it can't run then it can't be because of kernel changes. If it is because of kernel changes then its considered a bug to be fixed.

    Whatever implementation of revoke() goes into the kernel has to be perfect on the first run or extensible enough to not matter.

    Comment


    • #17
      Hmm, maybe if there were a revoke() implementation as a loadable kernel module?

      Comment


      • #18
        Originally posted by uid313 View Post
        Hmm, maybe if there were a revoke() implementation as a loadable kernel module?
        That creates a problem of availability. It couldn't be used because it couldn't be guaranteed to be available. And Wayland would probably need it to be available on all systems.

        Comment


        • #19
          It's their model

          Something new comes along and they delete the old.

          GEM vs EXA vs XXA

          Then there was DRI vs DRI2.

          Modesetting.

          The list grows but I still blame distributions for screaming "Upstream" more than senators scream "Bipartisanship".

          It's getting old.

          You just can't keep up. I commend Nvidia for keeping up with the Jones'.

          Comment


          • #20
            Originally posted by squirrl View Post
            Something new comes along and they delete the old.

            GEM vs EXA vs XXA

            Then there was DRI vs DRI2.

            Modesetting.

            The list grows but I still blame distributions for screaming "Upstream" more than senators scream "Bipartisanship".

            It's getting old.

            You just can't keep up. I commend Nvidia for keeping up with the Jones'.
            GEM has nothing to do with EXA and XXA, GEM is still still being used in kernel (Wayland is pretty much dependent on it cuz everything is a GEM object or is a GEM handle)

            DRI was supplanted by DRI2...which was in the X server, not the kernel. The x server drops stuff.

            Modesetting moved from the X server (userspace) to the kernel (KMS)

            Nvidia keeps up because...they replace most of the stack with their own pieces because of cross-platform support


            Wanna try again squirrl?

            Comment


            • #21
              Originally posted by Ericg View Post
              Yuuuuuuuuuup. Remember, kernel policy is anything that ever hits mainline that userspace can use can never break. Ever. If someone wants to run a motif app from 1995 that was designed around kernel 2.4.12 (im picking a random release number there lol), that app has to work as far as the kernel is concerned. It can break because of userspace changes, thats fine, but if it can't run then it can't be because of kernel changes. If it is because of kernel changes then its considered a bug to be fixed.

              Whatever implementation of revoke() goes into the kernel has to be perfect on the first run or extensible enough to not matter.
              I'd say it would be ideal if it were extensible.

              That motif app from 1995 would be an elf or a.out binary for Linux 1.2, though-and I've run Gimp 0.54 release binaries recently, which come pretty close.
              (Just curiousity; yes, you probably would prefer the newer version. It's comparable to xpaint for the most part.)

              Allegedly, at one point they made sure that the original bash from when Linux binaries were first released still worked.

              Comment


              • #22
                Originally posted by Ericg View Post
                GEM has nothing to do with EXA and XXA, GEM is still still being used in kernel (Wayland is pretty much dependent on it cuz everything is a GEM object or is a GEM handle)

                DRI was supplanted by DRI2...which was in the X server, not the kernel. The x server drops stuff.

                Modesetting moved from the X server (userspace) to the kernel (KMS)

                Nvidia keeps up because...they replace most of the stack with their own pieces because of cross-platform support


                Wanna try again squirrl?

                You obviously didn't get the point!
                They keep changing everything is the point.
                Stuff moves in and out of the Xserver on Whim!
                GEM has tendrils in Xserver too
                Besides, it may be in the kernel now, but later it'll be in Xserver totally.
                there I tried again.

                Comment


                • #23
                  Originally posted by squirrl View Post
                  You obviously didn't get the point!
                  They keep changing everything is the point.
                  Stuff moves in and out of the Xserver on Whim!
                  GEM has tendrils in Xserver too
                  Besides, it may be in the kernel now, but later it'll be in Xserver totally.
                  there I tried again.
                  Things were in the X server because they wanted it to be cross-platform. This happened before, the X server once upon a time had a printing server inside of it because they wanted to be cross-platform. Once the issue of cross-platform got taken out of the equation, then things started to be moved out of the X server and into the kernel.

                  I really cant think of anything that was taken from the x server, put into the kernel, and then put back into the x server...

                  And yes, things do keep changing because the linux graphics stack was at one point about 10 years out of date, now we're playing catchup and trying to get a solid footing on things. So there will be a lot of chaos until things settle (which they are now, the move forward is Wayland which will remove the giant middle-man that is the X server out of the way)

                  Comment


                  • #24
                    DRI is about 15 years old; DRI2 has been in the X server for 5 years now.

                    XAA is 17 years old; EXA is 8 years old; UXA is 5 years old.

                    The original modesetting infrastructure is nearly 20 years old; RandR 1.2 is 7 years old, and the five-year old KMS is a fairly literal port of the RandR 1.2 API into kernel space.

                    Considering how much technology has changed since 1996, is that actually too fast a rate of change for you?

                    Comment


                    • #25
                      Originally posted by Ericg View Post
                      Things were in the X server because they wanted it to be cross-platform. This happened before, the X server once upon a time had a printing server inside of it because they wanted to be cross-platform. Once the issue of cross-platform got taken out of the equation, then things started to be moved out of the X server and into the kernel.
                      Xprint got removed because it was a terrible, terrible, terrible idea that fulfilled none of its goals and made everyone deeply unhappy. http://cgit.freedesktop.org/xorg/xprint/log/ should give you an idea of how popular it is.

                      Comment


                      • #26
                        I wish the development was more effective so we had less bugs.

                        Comment


                        • #27
                          There are problems in the design of X that prevents it from being fixed without breaking everything. Breaking everything gives you an opportunity to design it from scratch properly.

                          Comment


                          • #28
                            Originally posted by daniels View Post
                            DRI is about 15 years old; DRI2 has been in the X server for 5 years now.

                            XAA is 17 years old; EXA is 8 years old; UXA is 5 years old.

                            The original modesetting infrastructure is nearly 20 years old; RandR 1.2 is 7 years old, and the five-year old KMS is a fairly literal port of the RandR 1.2 API into kernel space.

                            Considering how much technology has changed since 1996, is that actually too fast a rate of change for you?
                            XAA and DRI is removed now?
                            Is EXA removed yet? Can it be removed? Will it be removed?
                            Now DRI3 is on the way, so when that happens, will DRI2 be removed?

                            What else can be removed?

                            Originally posted by varikonniemi View Post
                            There are problems in the design of X that prevents it from being fixed without breaking everything. Breaking everything gives you an opportunity to design it from scratch properly.
                            Somethings cant be fixed/changed without breaking everything.
                            But maybe we can remove lots of things that nobody uses these days.
                            Sure, X.org Server wont be 100% compliant with X11 anymore, but at least we will have got rid of lots of old legacy cruft, and made the code base smaller and more easier to maintain.

                            Comment


                            • #29
                              Originally posted by uid313 View Post
                              XAA and DRI is removed now?
                              Is EXA removed yet? Can it be removed? Will it be removed?
                              Now DRI3 is on the way, so when that happens, will DRI2 be removed?

                              What else can be removed?

                              I'm not sure if they can removed, because of applications still using them (maybe not DRI, but def DRI2) XXA has been partially supplanted by EXA though there is still a driver or two using XXA.

                              Somethings cant be fixed/changed without breaking everything.
                              But maybe we can remove lots of things that nobody uses these days.
                              Sure, X.org Server wont be 100% compliant with X11 anymore, but at least we will have got rid of lots of old legacy cruft, and made the code base smaller and more easier to maintain.
                              1) At that point..we have Wayland :P
                              2) The problem with breaking Xorg and X11 compliance is I think Xorg is the X consortium now, so if they break the X protocol, that would imply X12 protocol...which is Wayland. But if they call it X12, then anyone who has any interest in X still would need to get the chance to chime in with what they think X12 should look like. Hence Wayland, it was a clean break from backwards compatibility and old people and old thoughts and ideas.

                              Comment


                              • #30
                                Originally posted by Ericg View Post
                                1) At that point..we have Wayland :P
                                2) The problem with breaking Xorg and X11 compliance is I think Xorg is the X consortium now, so if they break the X protocol, that would imply X12 protocol...which is Wayland. But if they call it X12, then anyone who has any interest in X still would need to get the chance to chime in with what they think X12 should look like. Hence Wayland, it was a clean break from backwards compatibility and old people and old thoughts and ideas.
                                No, if they just stripped away unused features so the X.org Server would not be a full implementation of the X11 protocol, then that would not be X12, it would be a partial implementation of X11 or a a implementation of a subset of the X11 protocol, or X11 light.

                                X12 is an another protocol and a discussed successor to the X11 protocol.
                                http://www.x.org/wiki/Development/X12

                                Also, Wayland is something different. Also, since Wayland can use XWayland to run X.org Server on top of Wayland, then we could still cut fat of X.org Server while using it together with Wayland.

                                Comment

                                Working...
                                X