Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 52

Thread: Differences Between X.Org, Wayland & Mir

  1. #41
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    238

    Default

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

  2. #42
    Join Date
    Mar 2011
    Posts
    374

    Default

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

  3. #43
    Join Date
    Sep 2010
    Posts
    653

    Default

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

  4. #44
    Join Date
    Sep 2010
    Posts
    653

    Default

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

  5. #45
    Join Date
    Sep 2012
    Posts
    650

    Default

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

  6. #46
    Join Date
    Sep 2010
    Posts
    653

    Default

    Quote 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; 03-26-2013 at 11:33 AM.

  7. #47
    Join Date
    Oct 2011
    Location
    Germany
    Posts
    238

    Default

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

  8. #48
    Join Date
    Sep 2012
    Posts
    650

    Default

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

  9. #49
    Join Date
    Jul 2011
    Posts
    344

    Default

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

  10. #50
    Join Date
    Sep 2010
    Posts
    653

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •