Announcement

Collapse
No announcement yet.

X.Org 7.8 Isn't Actively Being Pursued

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

  • #51
    Originally posted by erendorn View Post
    Yes, having to introduce modern display technology in a 30 yo codebase puts you in a very good place to know how to write a new codebase for that technology.
    as i said above, it also puts you at risk of being influenced by the programming style, conventions, concepts and tools of 30 years ago - a risk of which imho you have to be aware in order to consciously avoid it
    same for the risk of making questionable design choices in a modern project
    example - at the beginning, wayland was envisioned so that the server would only contain a window stack and receive hardware input firsthand, and
    clients would handle EVERYTHING regarding their windows - not only (re) drawing their own decoration, minimizing and maximizing, but also dragging and moving in full screen coordinates (their window being a full screen surface anyway, optionally surrounded with transparent pixels) stacking order (implying access to the global window stack in the compositor) forwarding click events to other clients and so on - a concept making the system as a whole more fragile (every application participates in the protocol and acts as a point of failure for every operation) and going against the principle of transparency above
    would you agree with this design?
    You seem to be confusing display technology
    to be precise, *display* technology is what comes out of intel, amd and nvidia, or SGI, Matrox, E&A and the others back in the day - X and wayland are about UI technology, consumers of display technology but not really at the same logical or sofistication level
    and programming technology.
    they are not one and the same (obviously), but they have to go step by step by a certain extent - as times change and what's the perfect tool for the job now may not be tomorrow
    so a good professional is ready to change tools and development languages and adapt
    Wayland developers are experts in display technology, while Mir devs are not (and no, it's not trivial).
    i develop 3d games and say they have all the same chances, and though not trivial, it's not out of their reach, either (as the main loop of a wyland like display server - what other OS's historically called "app-servers" - isnt all that different from the mainloop of a game, plus some specific requirements that need some thought but *can* be gotten right)
    you say the contrary - fine, on what basis?

    Comment


    • #52
      Originally posted by Luke View Post
      Are you referring to work inside AMD to get the code "cleaned," cleared, and released, or to parallel efforts like the old style power management and VDPAU decode on the shaders? I was using old-style "profile" power management since late Spring 2012.
      The former (although you need to add "written" to the front of your list ). The parallel efforts you mentioned started even earlier.
      Test signature

      Comment


      • #53
        Originally posted by silix View Post
        nope, it's not rocket science because it is about maintaining a scene graph, performing an input-redraw loop, move some surfaces around in screen relative coordinates, maybe devise a mechanism of sorts for applications to handle drag and drop, some hooks for input methods (ooohhh), and that's it mostly (it's not even about doing complex math for drawing curves or render scenes to surfaces, because what's in the rectangular surface/window is entirely up to the client)

        it's something that almost any sw engineer (starting with those working with games and game engines) could be tasked with
        It's quite a bit more than that... there's all the groundwork in lower parts of the stack that were necessary to do before a modern display system such as Wayland - or Mir - was possible, and a lot of this was done by Wayland developers. Support for legacy systems in the form of XWayland is another thing that requires experience from maintaining X.

        Sure, someone could probably cobble up a rudimentary display system with not much problems (Surfaceflinger... oh, I kid, android devs), especially for a homogenous system where there are not many, diverse use cases. But when you have to develop a protocol that is stable, sleek, and customizable to suit diverse needs ranging from mobile/embedded to desktops to workstations and render farms - that's a whole another issue. When you have to consider things such as colour management, buffer allocations, various pixel formats, etc. Go look at the Wayland mailing lists and see the amount of work that goes in every detail - these guys are very thorough, they don't want to rush it and create an inferior system that causes problems down the line.

        stop with this already...
        you'd be right if Mir were reusing code from weston - but unless you prove otherwise it's not
        Weston has very little to do with it since it's only a reference compositor, not meant for production use in actual DE's... Wayland != Weston, Wayland allows anyone to reimplement the protocol with their own compositor and use whatever language and all the test-driven programming and server-side buffer-allocations they want to do it.

        Then if we go to other parts of the stack, XMir is a direct copy of XWayland, only adapted to use Mir as a backend instead of a Wayland compositor - and patched to allow running rooted in order for Canonical to use it as a "clever" way to run X DE's - purely a PR move, so that the rubes and fanboys can say "see! Mir is already running! they're faster and better than Wayland!". Libhybris was also developed by a Jolla employee, originally for Wayland - which Canonical took and adapted to use for Mir.

        And like I said, there's a lot of work done outside of Wayland, in lower parts of the stack, that were necessary to make it possible to create a modern display system. Without that work being done, Mir couldn't exist, either.

        so the only thing they have in common is they are both compositing display servers doing away with X, which is quite vague
        There's a bit more than that, really. Mir is entirely unnecessary, there's nothing it does that couldn't be done with a Wayland compositor.

        moreover, there are at least two legacy (X11) -free gui servers, based on the mechanism of compositing, that predate Mir by a decade and Wayland by 5 years, and exploiting gpu capabilities (use the gl pipeline to render the desktop) is in the talk in the linux scene since at least 2004
        So? We don't see them in use anywhere. If they were any good, if they were viable alternatives for X, we'd be using them.

        moreover, wayland in itself is nothing special technically - doing away with X separate processes and round trips was the most logical thing anyone would do muche earlier than wayland - the problem has always been more with ecosystem inertia due to the mass of x based software
        Not so, and shows you don't really understand the tech... Wayland fixes many of the shortcomings and design flaws in X. It's also backend-agnostic, so that it is very flexible and can be used in diverse environments. And the thing is, you can say all you want that "someone could have done the same", but that's just a post-hoc rationalization - the truth is no one else did, and if there had been a better alternative in existence, there wouldn't have been any reason to create Wayland in the first place.

        had wayland not existed, it's not like nothing else would have ben born - someone else would have taken on the duty to port compositing from OSX and Longhorn to the free sw world, under a different project name
        Pointless speculation. There was a need for a new display system, and Wayland was born.

        dont need to ask, i perfectly know - so what? his words on C++ are utterly biased, all but pragmatic bs
        do i need take for dogma? no thank you .. read this http://warp.povusers.org/OpenLetters...oTorvalds.html and come back
        Before I read it, is the writer of that page the author of the largest software project in the world, a kernel that is the most popular OS kernel in the world, used in more diverse environments than any other, with code quality that is hailed as excellent by all the experts? If not, I'm likely to take Linus's word over theirs.

        it's worse than others in that it's not as fun, and you have to write twice (or more) as much code, actual code + code for intended behaviour + (ideally) code to check against unintended behaviour (or that wrong states or inputs are handled correctly)
        its' better in that you can stay assured that you have a consistent and working code base (granted all tests pass) at avery iteration - and, by breaking down individual features into tasks and subtasks, and implementing each atomically with the minimal possible code, that a project may build up features quicker
        Plenty of very good projects that don't need test-driven development... get over it, it's one method, not a panacea for all the programming problems of the world. Not suitable for every project, even.

        Besides that, other than libwayland, which is very sleek and light in code size in the first place, you can write your own Wayland compositor and use whatever-driven development you want.

        first, tdd is a development methodology - in itself it's ortogonal to the scale (business vs hobbyist) - in fact, it's something that may benefit a individual developer more because an individual may not have enough resource to devote in QA (which may well require an order of magnitude more effort) after hacking together the code
        second, it doesnt make it worse, either - if anything, it's better for you to know about it if you apply for a position with certain companies
        third, in several contexts the scale is what defines the level of professionalism involved with something, in the eyes of IT and non IT people - as a matter of fact "world class" is how a quality product is usually labeled, in contrast to "amateurish" ...
        fourth, mostly the same criteria apply to proprietary as well as free/ open source software (openness and/or ethos are another characteristic which is orthogonal to the methodology)
        You're the one who touted tdd as the best thing since sliced bread, or at least an advantage of Mir, yet now the best you can say of it is "it doesn't make it worse"...

        If you want to talk about "world-class" professionalism, Wayland is backed by corporations much larger and much more profitable than Canonical - Intel and Red Hat. There are professional, paid programmers involved in the project. Intel has interest in Wayland because they plan to use it in Tizen, which brings in Samsung as another interested party. Red Hat will use Wayland in RHEL 8.

        not always inferior, either..
        No, but no-one's claimed that.

        the linux kernel has very big commercial interests behind it, it's not really in the same league as what the wayland project (born in the spare time of a single employee) has been for the most of its life and still, to a certain extent, is
        The Linux kernel was also <i>born</i> in the spare time of a single CS student. It has grown since... and while there are commercial interests, they do not dictate the direction of development, and do not cause compromise in user freedom. Largely this is because of the GPL license, which allows corporations - even competitors - to collaborate without worrying about others gaining an edge from their work.

        Wayland was also grown since it was born, it's now being backed by Intel and Red Hat. Both have a lot more money than Canonical.

        i dont make assumptions on why you are the way you are, please dont make assumptions on what i read, either
        I just said it seems that way. Loosen up.

        so, make that one robust (and it's not impossible) and the whole is robust
        By the same logic, if you make each module robust, then the whole is robust.

        with separate components you have to make sure A, B and the protocol interconnecting them, are robust, first individually (unit) then when put together (integration) - separate components actually mean higher complexity and failure probability , leading to higher debug times..
        (SW development 101)
        If that's how you feel, fine, Wayland itself doesn't prohibit doing just that - all it requires is you to have a compositor to which clients talk according to the Wayland protocol. The compositor can be anything - it can be a window manager, a shell, a server, or all of above.

        Modularity also allows higher customization - it's the Unix way, do one thing and do it well.

        btw, interesting how you dont have a problem with the kernel being precisely a big chunk (>1 GB in some cases) of privileged code...
        Nicely said "in some cases"... The kernel has kernel modules, which you can pick and choose according to your needs - that's modularity. It's right in the name, module -> modularity.

        not that the display server, the compositor and the shell being separate processes under X, helped much in that regard.. if the x server crashed, all clients were terminated too and the system restarted, with your previous work, lost..
        the problem is not in the probability of a server crash - any software will crash soner or later, unless it's so simple and thoroughly verified that it wont- the problem lies in how the crash is handled
        but that is an orthogonal matter to the server being integrated or not - and graceful recovery can be implemented also for a server integrating the shell
        That's why the core protocol of Wayland and the library that implements it is streamlined and robust - less chance for a failure in Wayland itself. Wayland places no requirements to how the rest of it is implemented.

        ideally, the window manager / display server is transparent to applications and these would run without being aware of it and of each other (like processes run in a virtually flat memory space without being aware of each other or of the kernel scheduling them)
        even if that's not the case and some interaction between application and server is involved (at least for details such as input event forwarding, drag and drop and window min/max/resize -), you do realize that there's only so much protocol needed to accomodate a desktop, dont you?
        Wayland is transparent to the client - the client just speaks the Wayland protocol, draws to a buffer frame by frame, talks to the compositor to figure out how the buffers are allocated and such - in most cases, it doesn't need to care about other clients at all or know what the compositor is doing. The client doesn't even need to know where the surface "physically" (on the screen) is that it is drawing on, it's entirely up to the compositor to decide what to do with the surfaces and how to arrange them, all the client needs to know is "the buffer is here, draw to it" and it can trust the compositor to handle it getting on the screen, and each frame getting there in correct order.

        so please give a valid reason for why extensibility is needed (leading to multiple code paths in the server AND applications / toolkits, to fallback in the case of missing extensions either side / mismatched protocol version) that is not a vague "eh but the future you dont know..."
        Because Wayland will be used in diverse environments, and this gives developers a way to implement new features that they need without the need to get their patches committed to Wayland itself - if an extension becomes widespread enough or otherwise useful, it can then be added to the actual protocol.

        Most average clients won't have to worry about extensions at all, as all the features that most clients need are right there in the protocol - but in case special needs arise, the option is available. A client that is smartly written wouldn't want to depend on extensions that aren't widely used. Desktop environments, however, can use the extensions to implement their DE-specific tools and parts of the UI.

        Preparing for the future is smart, because tech moves on constantly.

        considering the above - the gui should be as transparent to applications as possible - and the fact Mir merges the WM with the shell, there's little need for something beyond a mir specific api for stuff like theming, input methods, the notification area, WM and DnD...
        Wayland otoh needs a protocol, having to support a different architecture (with possibly interchangeable shells , input methods and so on)
        That's the point, it means that no one else can use Mir, other than Unity. It's not a viable solution for anyone else, whereas Wayland is meant to run everywhere, for any configuration or platform.

        not having a protocol to develop against doesnt mean something is infeasible, it just means that the target is shifted - instead of developing at the protocol level for something that your application shouldnt know about, as you 'd do for wayland (to develop a compositor other than weston, out of process input method modules, or shells) you develop a mir plugin, or theme, or cutomize mir itself
        Yeah, thing is - if you customize Mir, there's no guarantee that it will remain compatible with Canonical's version, as they have explicitly stated that they will not go out of their way to maintain compatibility with reimplementations if they appear. So you'd in practice either have to constantly play catch-up with upstream, up to their whims - or you'd deviate from the original, not care what they do, and at that point you'd be creating a whole different, incompatible display server - so what was the point again, might as well have used Wayland...

        Or if you want to implement a Mir plugin - well, you face the same problem, they can change the API at any time and you have to play catch-up.

        Whereas, Wayland promises a stable API and protocol, both client and server side, so you can write a compositor against the current Wayland protocol and be sure that it works with any future versions, guaranteed. So the choice for all desktops is pretty much a no brainer, why would anyone even consider using Mir? DE developers aren't idiots, they've considered the options, and every one of them is going for Wayland (except if they want to stay with X for now). No one wants to use Mir, and the reason is obvious... no one trusts Canonical, who tend to "change their minds" and forget promises and outright lie when it suits them.

        Comment


        • #54
          tl;dr.



          .

          Comment


          • #55
            Originally posted by silix View Post
            realize that a display server is not exactly rocket science
            rather, it's like putting together individual low - and high level pieces, and envision objects (classes / methods) and data structures (in this case to support windows and their manipulation) as you would for any other sw problem, something that anyone who has studied sw engineering 101 and is given time to analyze the use case, requiremesnt and the APIs to use, for this one as would for any other problem, can do
            You should be quiet when you have no idea what you're talking about. What Wayland devs where doing the last 5 years is preparing everything (the kernel, mesa, ...). Surely they could have written a new display server without the ground work, but it would be ineficient as hell. Canonical needs the groundwork already done. BTW: That work isn't 100% finished - DRI3 is needed for XWayland to be production ready. Right now XWayland is more of a POC - the same counts for XMir but the "professionals" at Canonical seem to ignore that (instead of helping DRI3).

            Comment


            • #56
              Originally posted by TAXI View Post
              You should be quiet when you have no idea what you're talking about.
              i develop opengl sw for a living for the last 15 years, and follow the composited desktop since it was born in the form of Quartz Extreme (you won't really think Compiz came first, i hope ... that would be quite ignorant for someone so smug and arrogant as to silence others) and khristian hoegsberg's (along zack rusin's and many others, for that matter) blog since before wayland and its silly initial logo were a glint in his eyes - perhaps, just perhaps i know a thing or two more than you ...
              but WHO ARE YOU to tell someone to "stay quiet"?
              in a forum the only ones who can say something like that, are moderators (and even them, only with good reason - and i know, having spent 5 years on moderating a section on the largest italian IT forum) so i ask again: who are you, and what kind of authority are you invested with, to arrogantly silence someone you dont agree with?
              there's a saying here: give respect, you' ll earn respect - don give respect, earn nothing
              What Wayland devs where doing the last 5 years is preparing everything (the kernel, mesa, ...).
              work on DRI and KMS wasnt done ONLY by developers you now find on wayland - devel (many people on that mailing list are developers that debuted into desktop development with the wayland project - in some cases like proposing obviously kludgy and or inefficient solutions, their lack of field experience is manifest) - at the same time, not all X/mesa developers passed over to wayland ...
              but it doesnt matter, what matters is that it was work that had to be done anyway - not doing it would have meant not having anything to counter WDDM (yes, the architectural and driver model part of windows, what makes compositing possible on the most deployed desktop os) with, and sticking with AIGLX forever
              but apart from that, i suppsed work done in a central component (like the kernel) is meant to benefit ANY other project running on the kernel, not just ONE specific one .. nowhere is written that the wayland project shall be the sole (not only a privilged, but the only one) consumer of the API and mechanisms implemented by developers who worked on mesa (before the advent of wayland)..
              btw, did you know that, while now it seems obvious and granted that wayland would be the spiritual and actual successor to X, it was neither when it started?
              the same counts for XMir but the "professionals" at Canonical seem to ignore that (instead of helping DRI3).
              one may be right in saying that canonical is building a product to its own advantage, not out of "love for the community" - but then, what use is all the hatred? for someone who wants to do with as little effort as possible (if it's actually the case) for sure it's not an incentive to help .. on the contrary, it may only cause more reaction spite
              ("my product is targeted to people who wants something that just works, they wont care if i dont go out of my way to help infrastructure projects i'm not *obliged* to help - as long as it works... fanatic geeks will get mad at me, but that doesnt matter, since they're not my target..")
              Last edited by silix; 14 August 2013, 12:56 PM.

              Comment


              • #57
                Originally posted by silix View Post
                i develop opengl sw for a living for the last 15 years, and follow the composited desktop since it was born in the form of Quartz Extreme (you won't really think Compiz came first, i hope ... that would be quite ignorant for someone so smug and arrogant as to silence others) and khristian hoegsberg's (along zack rusin's and many others, for that matter) blog since before wayland and its silly initial logo were a glint in his eyes - perhaps, just perhaps i know a thing or two more than you ...
                Stop comparing games to display servers. Yes, you work with surfaces and things like that, too. But a game menu hasn't to be as responsive as a desktop. You won't really think Quartz Extreme came first, I hope, cause that was ~2000 while the first compositor was born ~1980.
                but WHO ARE YOU to tell someone to "stay quiet"?
                I didn't tell you to "stay quiet", I told you that sometimes it's better to be quiet to not look like an idiot.
                work on DRI and KMS wasnt done ONLY by developers you now find on wayland
                Where exactly did I say that? What I said was that the wayland developers worked on it to make it ready for a modern display server.
                at the same time, not all X/mesa developers passed over to wayland ...
                Nice that you try to lay some things in my mouth I never said...
                but it doesnt matter, what matters is that it was work that had to be done anyway
                Not for X.org - X.org was a death end. Now for what if not X.org did they do it?
                not doing it would have meant not having anything to counter WDDM
                Compositing support was not done for Wayland, that's where you're right. But that doesn't make my points invalid.
                and sticking with AIGLX forever
                Why do we talk about AIGLX now?
                but apart from that, i suppsed work done in a central component (like the kernel) is meant to benefit ANY other project running on the kernel, not just ONE specific one
                But it was done with one specific project in mind.
                nowhere is written that the wayland project shall be the sole (not only a privilged, but the only one) consumer of the API and mechanisms implemented by developers who worked on mesa (before the advent of wayland)..
                Did I say that? I don't think so. All I tried to tell you is that Mir is direcly dependand on that ground work and cause of that you can't compare development of Waylnd and Mir. If these things weren't done for Wayland Canonical would have to write them right now. Go give them the graphic stack we had 5 years ago and tell them to implement Mir on it. I would bet that they fail.
                btw, did you know that, while now it seems obvious and granted that wayland would be the spiritual and actual successor to X, it was neither when it started?
                What exactly does this have to do with the discussion we're having? Want to look cool?
                one may be right in saying that canonical is building a product to its own advantage, not out of "love for the community" - but then, what use is all the hatred? for someone who wants to do with as little effort as possible (if it's actually the case) for sure it's not an incentive to help .. on the contrary, it may only cause more reaction spite
                If they would want to do as little work as possible they would have written a Wayland compositor. There's no technical reason for Mir. The only thing it does is slowing down everything.
                ("my product is targeted to people who wants something that just works, they wont care if i dont go out of my way to help infrastructure projects i'm not *obliged* to help - as long as it works... fanatic geeks will get mad at me, but that doesnt matter, since they're not my target..")
                Fine, Wayland "just works". So why we need Mir again? And for not the target: You do realise that Ubuntu needs "the geeks" as it is a Linux OS (so almost everything they use is made by "the geeks") ?
                Also: When you write a game and want to use some 3rd party library would you use it when the developers of it say "right now it's more of a POC and not production ready" just because in your eyes it "just works" ?

                Comment

                Working...
                X