Announcement

Collapse
No announcement yet.

Differences Between X.Org, Wayland & Mir

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

  • #41
    Originally posted by przemoli View Post
    Mir vs Wayland support in toolkits will look SAME. No technical reasons that would make one or second "better".

    And Upstart was BEST solution, that get support from across Linux landscape. systemd started latter AFTER some devs decided that Upstart in not perfect. (Just like now some devs decided that Wayland isn't perfect ) Heck Upstart landed in RHEL, that is probably best know "solid software" badge in Linux world.
    Init Systems and Display Managers are different you can replace the first without changing anything than the programm itself.
    But this doesn't applys to Display Managers.

    Comment


    • #42
      Originally posted by Vim_User View Post
      There is still no final data on what will be in the Steambox by default (not even if the default Steambox will even feature an AMD or Nvidia GPU).
      But let's just for argument's sake assume that the final default design of the Steambox features an APU from AMD and a customized Ubuntu LTS running with Xorg.
      This is irrelevant as the default Steam Box won't matter for others. Valve itself will release more than one version of it and others will do, too. So there will be various boxes using different APU and/or CPU/GPU solutions. That means the best bet for an APU / GPU producer to get many deals with many Steam Box producers will be to have good drivers for customer hardware.

      Comment


      • #43
        Originally posted by Thaodan View Post
        Init Systems and Display Managers are different you can replace the first without changing anything than the programm itself.
        But this doesn't applys to Display Managers.
        No.

        Then you NEED to rewrite all the startu/shutdown/freeze/hibernate/suspend scripts...
        Or you use compatibility layer and then you gain nothing.

        Same as with display server. Both Wayland and Mir will have X compatibility layers, where app will not gain anything, and will not have to be changed.

        And only code that target X API's will need to be changed. Which for majority of app mean 0. Just replace Graphic toolkits with versions supporting Mir/Wayland backend.



        As you can see I do not write just Wayland or just Mir. They both will need same measures.

        Comment


        • #44
          Originally posted by TAXI View Post
          This is irrelevant as the default Steam Box won't matter for others. Valve itself will release more than one version of it and others will do, too. So there will be various boxes using different APU and/or CPU/GPU solutions. That means the best bet for an APU / GPU producer to get many deals with many Steam Box producers will be to have good drivers for customer hardware.
          Its hard to tell. Valve may wish to put all "Steam box" candidates under some strict requirements for perf/power efficiency, etc.

          And others will either not use Valve Steambox brand or will target Win usage instead of any Linux.

          Comment


          • #45
            Originally posted by przemoli View Post
            Then you NEED to rewrite all the startu/shutdown/freeze/hibernate/suspend scripts...
            Or you use compatibility layer and then you gain nothing.
            Still easier than rewriting closed graphic drivers.

            Comment


            • #46
              Originally posted by erendorn View Post
              Still easier than rewriting closed graphic drivers.
              Canonical may ease that problem, and it will mean better gpu driver model on desktop.. They use Android gpu drivers just fine.

              And currently both Mir and Weston require rewrite of proprietary drivers.

              So its still true that both will require similar work.
              Last edited by przemoli; 26 March 2013, 11:33 AM.

              Comment


              • #47
                Originally posted by przemoli View Post
                Canonical may ease that problem, and it will mean better gpu driver model on desktop.. They use Android gpu drivers just fine.
                On Desktop the use libdrm, on mobile the use android drivers with libhybris. But this is nothing that you can't do with wayland.

                Comment


                • #48
                  Originally posted by przemoli View Post
                  Canonical may ease that problem, and it will mean better gpu driver model on desktop.. They use Android gpu drivers just fine.

                  And currently both Mir and Weston require rewrite of proprietary drivers.

                  So its still true that both will require similar work.
                  That's the whole point. It will require twice the work, from outside the community, from corporations that are likely to be satisfied by doing the work only once. If you do a second init system and programs stop providing init scripts for upstart, canonical can just go on writing their init scripts themselves (they do it already). If you do a second display server and nvidia drops plans supporting the first, well good luck supporting their GPU on your own.
                  That's why init systems, or packaging systems, or core tools, or filesystems, or network managers or much of the whole Linux stack cannot be compared to the display server, in terms of cost of forking/going non standard.

                  Comment


                  • #49
                    Originally posted by erendorn View Post
                    That's the whole point. It will require twice the work, from outside the community, from corporations that are likely to be satisfied by doing the work only once. If you do a second init system and programs stop providing init scripts for upstart, canonical can just go on writing their init scripts themselves (they do it already). If you do a second display server and nvidia drops plans supporting the first, well good luck supporting their GPU on your own.
                    That's why init systems, or packaging systems, or core tools, or filesystems, or network managers or much of the whole Linux stack cannot be compared to the display server, in terms of cost of forking/going non standard.
                    I'm not completely sure but I think this blog is about Upstart (from the original creator of Upstart) netsplit.com/2012/10/30/goodbye-ubuntu/ I get the impression different Init system require different code to support software raid somehow. And apparently none in Canonical care about the code in Ubuntu as its not there focus. Red hat has there own code and so has debian with sysvinit.

                    Comment


                    • #50
                      Originally posted by erendorn View Post
                      That's the whole point. It will require twice the work, from outside the community, from corporations that are likely to be satisfied by doing the work only once. If you do a second init system and programs stop providing init scripts for upstart, canonical can just go on writing their init scripts themselves (they do it already). If you do a second display server and nvidia drops plans supporting the first, well good luck supporting their GPU on your own.
                      That's why init systems, or packaging systems, or core tools, or filesystems, or network managers or much of the whole Linux stack cannot be compared to the display server, in terms of cost of forking/going non standard.
                      That assume that whole Linux ecosystem should just love what Wayalnd cooks with proprietary gpu vendors, but when its Canonical than nobody is allowed to touch it...

                      No there will be just one new model for proprietary drivers. Wayland/Mir use it. However Wayland as a project was lacking leverage.. so it most probably be Mir team dictating what to change.

                      Do note that what ever GPU vendors will come up with, it wont be some hidden stuff, everybody will be able to use it...

                      Comment

                      Working...
                      X