Announcement

Collapse
No announcement yet.

Mir Development Stats Dominated By Canonical

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

  • phoronix
    started a topic Mir Development Stats Dominated By Canonical

    Mir Development Stats Dominated By Canonical

    Phoronix: Mir Development Stats Dominated By Canonical

    For those curious about the Mir Display Server development but aren't actively following its Bazaar development repository, the development continues to be dominated by Canonical and here's some numbers looking at the current development statistics surrounding Mir...

    http://www.phoronix.com/vr.php?view=MTM5NTg

  • verde
    replied
    Originally posted by uid313 View Post
    Canonical doesn't even want any third-party developers, they just want it developed in-house by themselves.

    Not very community spirit!
    did YOU tried to help and they said "NO"?

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by shaunehunter View Post
    Canonical wants to start putting out devices this fall. Wayland's ETA is sometime'ish. "Doing it right" has no value if it never gets done. Canonical seems to want Mir to be compatible with Android drivers and that may be the right call. I imagine the wayland team was about as receptive to working with Canonical as the GNOME project was.
    People have already addressed the other points, but this argument doesn't make sense, either. When Mir was announced, Wayland was already practically done. Yes, there are a few things left, but if Canonical really wanted those things quicker, they could have added their own versions of those things to Wayland via extensions (Wayland supports that), and be done with it, or even just fork Wayland temporarily. It would have taken a lot less work to do it that way and they would have been done with it far faster, probably even done with it right now. Neither of those solutions would have been ideal, but it would have been a lot quicker and less work for them, and would have been a lot less damaging to the ecosystem overall.

    Leave a comment:


  • oleid
    replied
    Originally posted by dee. View Post
    Quoting from your very first link:

    "Prior to version 1.2, the name of the EGL specification was OpenGL ES Native Platform Graphics Interface." No, EGL isn't OpenGL ES, it's OpenGL ES Native Platform Graphics Interface. I mixed that up in the first place, however, corrected that in my 2nd post.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by shaunehunter View Post
    What and where do you buy it. I probably would buy it. Really.

    I'm not hating on Wayland, I'm waiting on it.
    Honestly i don't know, it's not in smartphones, but it's in some newer ivi's (cars) and tvs, and other such systems. Devices that don't tend to advertise their underlying technology to geek sites, but just want something that works.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by IsacDaavid View Post
    not pretending to drive the conversation to a different path, but in cases like this it feels desirable to have an advertising clause or some sort of attribution requirement in the license itself.
    Maybe, but it would also be nice not to *need* an anti-asshole clause in the license. Canonical aren't doing anything the license doesn't permit, but with this kind of shit, it's little wonder the rest of the community doesn't trust them much.

    Leave a comment:


  • mrugiero
    replied
    Originally posted by jrch2k8 View Post
    for @mrugiero

    1.) well if you have a complex desktop maybe it make no sense to discard a compositor but imagine you have an ARM HTPC that you want to autostart XBMC, well XBMC don't need the compositor since it will always be fullscreen and is better for it to have 100% of the GPU resources dedicated to it, instead of wasting cycles in keep a compositor for the sake of it
    You are right, I just assumed we were talking about desktop. I usually forget there are smartphones and all kind of things out there, mostly because my only personal computing device is a laptop. I still use a Nokia 1100 :lol:
    2.) well if you are in a complex desktop enviroment like KDE or Gnome well the compositor need to know[you have IPC API for that] that you want full control of the GPU and given its smart enough it will use any method it can to remove itself of the GPU to give control to that App. As the how it will depend of the compositor but for example Kwin could copy all the non full screen surfaces to an SHM buffer and flush the GPU to pass it to the App and once you wish to switch or de maximize the compositor will composite in that SHM buffer while is been copied back to the framebuffer or it could simply keep other surfaces in in the framebuffer tagged as offscreen so it will consume some GPU memory but stay entirely away of the render process or any other method the compositor can handle[very rich set of options to play with].

    as a rule of thumb remember composite basically means create a single surface using many layers of smaller surfaces outside the scope of you own application[in wayland you can composite effect within your app], so if you control the only surface available cuz is full screen and you own the process and the compositor is not needed because there is nothing to composite[note that eye candy is not part of the composite stage but the render stage and you control the render stage from the app GPU wide if fullscreen or surface owned wide if you are in a multi surface scenario]
    Thanks for the clarification. I'm aware what compositing means, and I actually put a lot of thought last week to this (but kept forgetting to check if it was actually done this way).

    Leave a comment:


  • jrch2k8
    replied
    for @mrugiero

    1.) well if you have a complex desktop maybe it make no sense to discard a compositor but imagine you have an ARM HTPC that you want to autostart XBMC, well XBMC don't need the compositor since it will always be fullscreen and is better for it to have 100% of the GPU resources dedicated to it, instead of wasting cycles in keep a compositor for the sake of it

    2.) well if you are in a complex desktop enviroment like KDE or Gnome well the compositor need to know[you have IPC API for that] that you want full control of the GPU and given its smart enough it will use any method it can to remove itself of the GPU to give control to that App. As the how it will depend of the compositor but for example Kwin could copy all the non full screen surfaces to an SHM buffer and flush the GPU to pass it to the App and once you wish to switch or de maximize the compositor will composite in that SHM buffer while is been copied back to the framebuffer or it could simply keep other surfaces in in the framebuffer tagged as offscreen so it will consume some GPU memory but stay entirely away of the render process or any other method the compositor can handle[very rich set of options to play with].

    as a rule of thumb remember composite basically means create a single surface using many layers of smaller surfaces outside the scope of you own application[in wayland you can composite effect within your app], so if you control the only surface available cuz is full screen and you own the process and the compositor is not needed because there is nothing to composite[note that eye candy is not part of the composite stage but the render stage and you control the render stage from the app GPU wide if fullscreen or surface owned wide if you are in a multi surface scenario]

    Leave a comment:


  • IsacDaavid
    replied
    Originally posted by jrch2k8 View Post
    here is the blog post http://mer-project.blogspot.fi/2013/...u-drivers.html

    and the quote from the dev himself

    "Earlier this year however, I discovered that a well-known company had taken the code - disappeared underground with it for several months, improved upon it, utilized the capability in their advertisements and demos and in the end posted the code utilizing their own source control system, detached from any state of that of the upstream project's. Even to the extent some posters around the web thought libhybris was done by that company itself."
    not pretending to drive the conversation to a different path, but in cases like this it feels desirable to have an advertising clause or some sort of attribution requirement in the license itself.

    Leave a comment:


  • shaunehunter
    replied
    Originally posted by smitty3268 View Post
    Wayland is actually shipping in real, live, consumer products. Today. Not just downloadable tech demos.
    What and where do you buy it. I probably would buy it. Really.

    I'm not hating on Wayland, I'm waiting on it.

    Leave a comment:

Working...
X