Does The Display Server Matter? The Latest Mir vs. Wayland Argument

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

  • deck
    replied
    Originally posted by bison View Post
    From Martin's response:



    I'm not sure who "all of us" is supposed to be, but this comment displays enormous levels of arrogance and entitlement. Are the rest of us supposed to check with "all of us" before starting a new software project? Do we need to get permission to proceed? Do Wayland developers, or KDE developers -- or any other arbitrary group of developers -- have exclusive rights to dictate how software will be written for Linux-based operating systems, or for any other operating system?

    I think not.
    You have got that pretty much exactly backwards. It is Canonical that is being arrogant, trying to flex their muscle in this space, or if taking a less cynical view, simply trying to advance their own priorities at the expense of FOSS interoperability.

    "All of us" is likely meant to represent the FOSS dev community in general; where the overwhelming support is behind Wayland.

    Leave a comment:


  • dee.
    replied
    Originally posted by tuubi View Post
    Did Canonical actually commit to a stable API at some point? I remember them stating that there are no guarantees and that they have no (financial, I guess) interest in supporting anything but Unity.
    That's the problem... they don't know what they want. On one hand, they say they want their own display server because they can tailor it for the needs of Unity and don't have to care about other DE's. But then they turn around and say that they wish other DE's will adopt Mir and it will become more popular than Wayland (as if)...

    Seems like Canonical doesn't even know what it wants to do... or they're just sending very mixed messages.

    Leave a comment:


  • Pajn
    replied
    Originally posted by TheBlackCat View Post
    Did they actually make a commitment to keep the API stable, or is this just a goal they may or may not meet?
    I don't know what's a goal and what's a commitment but having a stable API is something they want
    when things starts to cool down a bit.

    We need ABI stability in libmirserver and proper soname handling. Once it's assured: - we'll add a symbols file (upstream Mir packaging) - change the dependency to not force dependency to match the exact version of Mir it was built against (upstream Mir, u-s-c and unity-mir packaging) - not force rebuilding anymore unity-mir and u-s-c when there is a mir change (daily-release side) - merge u-s-c and mir stacks (daily-release side)


    If you want a statement from Mark, then no I don't think such exists, however I don't usually
    read what he writes.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by Pajn View Post
    Yes they want to keep the API stable (even for there own usage). This has been brought up multiple times on the mailing list.
    Did they actually make a commitment to keep the API stable, or is this just a goal they may or may not meet?

    Leave a comment:


  • Pajn
    replied
    Originally posted by tuubi View Post
    Did Canonical actually commit to a stable API at some point? I remember them stating that there are no guarantees and that they have no (financial, I guess) interest in supporting anything but Unity.

    Then again, I haven't exactly been keeping up with Mir as it's pretty much irrelevant for most of us in any case. I tend to skip any news or threads about Ubuntu-specific tech.
    Yes they want to keep the API stable (even for there own usage). This has been brought up multiple times on the mailing list.
    However they wont be adding features that other compositors may like as they only care about Unity, with that said, Unity
    isn't so extremely special so most other DEs would probably find the features enough anyway.

    Also by telling people to not use the protocol they aren't held back in any way by having a stable API as
    they just can add added features under other functions or namespaces. And if they change an existing feature
    they could remap the API so it externally behaves the same anyway.

    Leave a comment:


  • tuubi
    replied
    Originally posted by Pajn View Post
    Because they guarantee the API and not the protocol they may change the protocol without breaking
    anything, as everything outside Mir (even Unity) are supposed to use the API.
    Did Canonical actually commit to a stable API at some point? I remember them stating that there are no guarantees and that they have no (financial, I guess) interest in supporting anything but Unity.

    Then again, I haven't exactly been keeping up with Mir as it's pretty much irrelevant for most of us in any case. I tend to skip any news or threads about Ubuntu-specific tech.

    Leave a comment:


  • Pajn
    replied
    Originally posted by TAXI View Post
    And you're still saying Mir doesn't have a protocol but is using API calls instead?
    Well, Mir does have a protocol but you shouldn't use it as it isn't stable and may get replaced over night.
    You shall use the API where they guarantee stability. By doing that you don't have to know anything about
    the protocol and they may change it without your program (whatever it is a client or a compositor) breaking.

    Originally posted by Ericg View Post
    if I remember correctly Mir Compositors depend / include libmir (name might be wrong but its the Mir API library) . Its part of the reason why when Canonical announced Mir they explicitly mentioned that API/ABI are not guaranteed for anything except Unity. If you depend upon libmir and Canonical pushes out an update to libmir that breaks API/ABI then any compositor other than Unity will be unusable until they also push out an update that handles the new API/ABI.
    See my answer to TAXI. If you use the API, as you should, it won't break.

    Originally posted by erendorn View Post
    Wouldn't the same happen if they had a protocol and changed it?
    Because they guarantee the API and not the protocol they may change the protocol without breaking
    anything, as everything outside Mir (even Unity) are supposed to use the API.

    Leave a comment:


  • erendorn
    replied
    Originally posted by Ericg View Post
    if I remember correctly Mir Compositors depend / include libmir (name might be wrong but its the Mir API library) . Its part of the reason why when Canonical announced Mir they explicitly mentioned that API/ABI are not guaranteed for anything except Unity. If you depend upon libmir and Canonical pushes out an update to libmir that breaks API/ABI then any compositor other than Unity will be unusable until they also push out an update that handles the new API/ABI.
    Wouldn't the same happen if they had a protocol and changed it?

    Leave a comment:


  • valeriodean
    replied
    Originally posted by toka View Post
    Don't the Nvidia propietary drivers support EGL?
    Wasn't EGL 1.5 released at the GDC?


    I don't see your problem.

    Question: there were/are some Wayland-specific stuff added to the EGL in Mesa. Ist this sill required or was it adopted into EGL 1.5?
    I don't know the details of the EGL support by the proprietary driver, but do you mean that when those driver will support EGL 1.5 everyone will work out-of-the-box with wayland compositor?

    Leave a comment:


  • Ericg
    replied
    Originally posted by TAXI View Post
    And you're still saying Mir doesn't have a protocol but is using API calls instead?
    if I remember correctly Mir Compositors depend / include libmir (name might be wrong but its the Mir API library) . Its part of the reason why when Canonical announced Mir they explicitly mentioned that API/ABI are not guaranteed for anything except Unity. If you depend upon libmir and Canonical pushes out an update to libmir that breaks API/ABI then any compositor other than Unity will be unusable until they also push out an update that handles the new API/ABI.

    Leave a comment:

Working...
X