Announcement

Collapse
No announcement yet.

Canonical Joined The Khronos Group To Help Mir/Wayland Drivers

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

  • smitty3268
    replied
    Originally posted by justmy2cents View Post
    p.s. if it sounds like trolling, blame it on my poor english, i'm genuinely interested in your answer
    The truth is that toolkits will take care of 99% of the issues by abstracting away the window system underneath. But 1% of a million different apps is still a very significant undertaking.

    One of the divides between acadamia and practicing software developers is that acadamia always sees the theory and how well everything should work. Developers see what happens in real life, and it's never nearly as clean as everyone hopes.

    The real issue I think is less the porting process for apps, but the testing process. It's going to be very difficult to properly test things (fully and constantly) on all 3 servers (X, Wayland, and Mir) and there are going to be times when Mir breaks assumptions that they would like to keep in the code for Wayland, and no one is really going to want to have to deal with that when there isn't a good reason for it. The only reason it's even a possibility is because fundamentally Wayland and Mir are so similar - if we were talking about another change as big as the one between X and Wayland is, there would be a full-scale revolt among developers.

    *Compositors, like Kwin are a different animal than regular apps, and have much much more trouble, which is why i don't expect kwin to run on Mir anytime soon. The problem is much less severe for most other apps.
    Last edited by smitty3268; 28 August 2014, 01:15 AM.

    Leave a comment:


  • justmy2cents
    replied
    Originally posted by blackout23 View Post
    Ohh yeah toolkits are going to save the day lol. Except for all the irrelevant apps that don't use any of the above mentioned toolkits like you know Firefox (XUL) or Chromium (Aura). Pretty sure the Steam client also uses it's own Toolkit as does the Unreal Engine 4 Editor.
    those use toolkits too and you already named them. XUL and Aura. both ported to wayland. while Steam fully uses SDL which was one of the last changes. Unreal engine uses Slate based on SDL which is not really perfect. while reading the irc logs, i noticed that developers porting it got stuck with SDL deficiencies (top window always grabbing focus, no transparency and few others so they are temporarily using X11 now, while Epic is promoting fixing SDL). don't know about support for mir and i don't even care

    then again, this wayland/mir will probably be evolutionary irrelevant. same as evolution is forcing MS out of their lock-in shell and adapt to service for everyone business type. by the time first mir deployment in late 16 happens, there will be way too much wayland adoption already. ubuntu might have largest share in linux desktop, but it will be of same importance as MS who holds 95% of worlds desktops.

    95% might sound big number, but when they put PC/phone/tablet devices together, their market share is simply too low to be able to just continue with old strategy. and that is why MS focused on service for everyone now, it is the only way to reach larger market and at the same time if they don't they might become less and less relevant

    wayland already ships on phones, cars, soon on various distros (F21 should ship with wayland support, not default though). mir? only adopted by ubuntu phone and ubuntu and yet to reach first usable state that is not tech preview

    next thing is support from GPUs, NVidia and AMD will probably provide support for both, while Intel already decided to pick one. also, based that all toolkits decided on definite wayland support and unsure about mir, that will hopefully bury canonical in downstream patches and they'll just create mir as wayland compositor

    Leave a comment:


  • justmy2cents
    replied
    Originally posted by BlackStar View Post
    As an app and a toolkit dev, you are wrong.

    GTK, Qt and SDL only offer a subset of functionality. To do some things, you must reach out to X, Wayland and Mir directly, and that means you now have 3x code to write.

    Canonical wants you to believe that the porting issue will magically disappear. They are lying.
    ok, i'm not toolkit dev, i'm a simple app dev who has yet to call one method from X in his life, so i have to ask this. where in the world would you need to access wayland directly? AFAIK, wayland just provides toolkit with blank requested memory surface which is then used as texture painted inside wayland. how you paint on that surface it does not really matter as long as result is something wayland can use. main reason why people had to call X would probably be they actually used Window created in X11, not to mention they probably spent more time writing X extensions to go around some X problem.

    there is no wayland drawing api like X had it. same as there is nothing like X properties since wayland basically sandboxes your surfaces and that is it. so, please name one example where you would need to do it

    p.s. if it sounds like trolling, blame it on my poor english, i'm genuinely interested in your answer

    Leave a comment:


  • TheSoulz
    replied
    Sorry i couldnt edit my previus post to add this since 5 minutes had passed ( stupid rule should be at least 15m to edit :P )

    im gonna move on from this since i belive its unimportante, abstracting the display manager solve moust of the issues (or should) if not other solutions will be created i have no doubt.
    meanwhile theres other bigger issues like different packages and make dev's life way more harder then this.
    consider that

    Leave a comment:


  • TheSoulz
    replied
    Originally posted by TheBlackCat View Post
    http://blog.martin-graesslin.com/blo...r-does-matter/
    Sure, but it still means developers need to code three solutions to their problem instead of two. It is adding additional work that wouldn't have been necessary.

    There will never be tools to cover every use case. And writing the tools still requires three different code paths instead of two, so it doesn't change anything, it just pushs the same problem into a different part of the software stack.
    I've read that very fast and may have skiped stuff but some problems he presented are not truly valid, he created If wayland and then said what if then it dosent work on mir? create a if mir ...
    also he said "If the toolkit would just abstract away all the display server differences our applications libraries would not have crashed"
    like i said the previus post this could be created


    "Sure, but it still means developers need to code three solutions to their problem instead of two. It is adding additional work that wouldn't have been necessary."
    that would be ludacris, you would create a library inside the toolkit or something and all apps target it.
    if all apps created it inside theyr own code would be unnessary bloat.

    "There will never be tools to cover every use case. And writing the tools still requires three different code paths instead of two, so it doesn't change anything, it just pushs the same problem into a different part of the software stack."
    there never is, but for moust commun cases it would work farly well i belive, sometimes when you create something more fancy you already know you will have more work.
    Last edited by TheSoulz; 25 August 2014, 08:35 AM.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by TheSoulz View Post
    So you write your app once, and it should work everywhere if the toolkit is supported.
    That is a big "if". There is no guarantee that the toolkits will support Mir upstream. Canonical may need to keep their own patches (likely for GTK, unknown for Qt).

    And even if you are using a toolkit, and even if the toolkit ostensibly supports all three, there are always subtle differences in how the display servers behave that can lead to unexpected bugs. Trying to port stuff to wayland has led to the discovery of a lot of bugs in toolkits that weren't detected before because Wayland makes use of code-paths had not been used before or not been used in the same way. Mir will have the same problem, and have it even worse if Canonical has to maintain Mir in downstream patches.

    But, at least with Wayland these bugs will be likely to be detected earlier because the upstream developers will be targeting it. But, except for Canonical's own projects, most upstreams will not be targeting, or probably even testing significanly, on Mir. KDE, for example, uses continuous testing of all commits. They can't test Mir, however, because their testing environment does not run on Ubuntu, and no one else supports Mir.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by TheSoulz View Post
    can you give me a hard example where you would talk to the display server (x,mir,wayland) direcly?
    This weekend I read a blog post by Robert Ancell from Canonical claiming that the display server doesn’t matter . To quote the direct message: The result of this is the display server doesn&#…


    Originally posted by TheSoulz View Post
    even if there are these are todays problems since we only have 1 display server we didnt have the tools now that we have 3 we could possibly do like call somekind of API and the API figures out what display server the user is using then use the correct path to that display server so devs would target one single API, am i wrong???
    Sure, but it still means developers need to code three solutions to their problem instead of two. It is adding additional work that wouldn't have been necessary.

    Originally posted by TheSoulz View Post
    just beacuse today it may be an issue does not mean tools cant be created to solve them.
    There will never be tools to cover every use case. And writing the tools still requires three different code paths instead of two, so it doesn't change anything, it just pushs the same problem into a different part of the software stack.

    Leave a comment:


  • TheSoulz
    replied
    Originally posted by BlackStar View Post
    As an app and a toolkit dev, you are wrong.

    GTK, Qt and SDL only offer a subset of functionality. To do some things, you must reach out to X, Wayland and Mir directly, and that means you now have 3x code to write.

    Canonical wants you to believe that the porting issue will magically disappear. They are lying.
    Sure but its only SOME things right?
    and depends on the kind of apps, its not like sundently your app its gonna be 3 times bigger.

    can you give me a hard example where you would talk to the display server (x,mir,wayland) direcly?
    even if there are these are todays problems since we only have 1 display server we didnt have the tools now that we have 3 we could possibly do like call somekind of API and the API figures out what display server the user is using then use the correct path to that display server so devs would target one single API, am i wrong???
    new things = new problems = new solutions

    just beacuse today it may be an issue does not mean tools cant be created to solve them.

    Originally posted by blackout23 View Post
    Ohh yeah toolkits are going to save the day lol. Except for all the irrelevant apps that don't use any of the above mentioned toolkits like you know Firefox (XUL) or Chromium (Aura). Pretty sure the Steam client also uses it's own Toolkit as does the Unreal Engine 4 Editor.
    sure like big companies like google are gonna have a big problem with it...
    they (googl3) even have new tools for mir/wayland right now, what was it called? ozone?
    think it helps to hardware accelerate grapichs.


    The resume its simple, people are freaking out over stupid things that can be solve (if they werent already) when there are other bigger issues that require more attention.
    Last edited by TheSoulz; 25 August 2014, 06:11 AM.

    Leave a comment:


  • blackout23
    replied
    Originally posted by TheSoulz View Post
    or none of the above...
    The way i understand it is:
    You as a app dev write to gtk or qt or whatever....
    tookits (gtk, qt, whatever name here) writes to x, mir, wayland and other stuff.
    games write to SDL so even them dont worry about it.

    So you write your app once, and it should work everywhere if the toolkit is supported.

    Im not a app dev but if you are and know prove me wrong
    Ohh yeah toolkits are going to save the day lol. Except for all the irrelevant apps that don't use any of the above mentioned toolkits like you know Firefox (XUL) or Chromium (Aura). Pretty sure the Steam client also uses it's own Toolkit as does the Unreal Engine 4 Editor.

    Leave a comment:


  • erendorn
    replied
    Originally posted by Pajn View Post
    That's a CLA and if you had ever signed one you would know the difference.
    I used CA for Contributor Agreement, but now I see it was an error as it got you confused and quite buthurt.
    I should have known that here the littlest subtleties can be easily nitpicked, my bad.

    Leave a comment:

Working...
X