Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 36

Thread: Mir Display Server Now Supports VT Switching

  1. #11
    Join Date
    Aug 2011
    Posts
    542

    Default

    Quote Originally Posted by TheOne View Post
    I wonder why canonical choose the client/server model for the Mir display server (same as X) while it was said that the big deal of Wayland was that it was client only, which would improve performance.

    Also I remember a lot of wars from people bitching about network transparency been lost because of this method used by the Wayland library. Maybe porting to Mir from X will be more easier (while keeping features) than porting to Wayland?
    You're severely misinterpreting the nomenclature here. "Server/client" model does not imply network transparency.
    Wayland calls the compositor "server" and any application displaying buffers through it "client", the same way that Mir does.
    This is for easier distinguishing between the software parts.

  2. #12
    Join Date
    Mar 2013
    Posts
    182

    Default

    Quote Originally Posted by Ancurio View Post
    You're severely misinterpreting the nomenclature here. "Server/client" model does not imply network transparency.
    Wayland calls the compositor "server" and any application displaying buffers through it "client", the same way that Mir does.
    This is for easier distinguishing between the software parts.
    mmm, so in other words it just 2 library files, one called libmirserver.so and other called libmirclient.so I thought it was something similar to the X way of working

  3. #13
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,911

    Default

    Quote Originally Posted by TheOne View Post
    Also I remember a lot of wars from people bitching about network transparency been lost because of this method used by the Wayland library. Maybe porting to Mir from X will be more easier (while keeping features) than porting to Wayland?
    You're obviously new, TheOne,because the network transparency debate was ended a long time ago.

    Here's the short version. X's biggest failing was in Network Transparency. You literally cant make a network transparency system WORSE than X while still trying to make a practical one. The core of Wayland network rendering will act a lot like VNC, but a Remote Desktop backend has already been merged so if you're an RDP fan, you're being taken care of too

    As far as the porting issue goes... you don't target Wayland, or X, or Mir. You target Qt, GTK, and EFL, as long as those toolkits have support for the display server you're targeting you're fine. For the record though... Qt is backing Wayland, GTK is backing Wayland, and EFL is backing Wayland. If Canonical wants those toolkits to support Mir as well, they will have maintain out-of-tree patches that they apply to the toolkit everytime they rebase off upstream.

  4. #14
    Join Date
    Mar 2013
    Posts
    182

    Default

    Quote Originally Posted by Ericg View Post
    ...
    Here's the short version. X's biggest failing was in Network Transparency. You literally cant make a network transparency system WORSE than X while still trying to make a practical one. The core of Wayland network rendering will act a lot like VNC, but a Remote Desktop backend has already been merged so if you're an RDP fan, you're being taken care of too
    ...
    I read that somewhere but wasn't sure what was so special about network transparency on X beside been able to forward windows using ssh with minimal data transfer involved. And since canonical made Mir in 2 libraries I wasn't sure if the same could be achieved, but now I see is just that, 2 libraries, no networking involved.

    Quote Originally Posted by Ericg View Post
    ...
    For the record though... Qt is backing Wayland, GTK is backing Wayland, and EFL is backing Wayland. If Canonical wants those toolkits to support Mir as well, they will have maintain out-of-tree patches that they apply to the toolkit everytime they rebase off upstream.
    That sounds like a lot hell of work

  5. #15
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    316

    Default

    Quote Originally Posted by Ericg View Post
    Qt is backing Wayland.
    Wrong! Qt supports Wayland. There is no public statement from of Digia or the Qt community that Mir will not be supported. Given that the effort to support Mir is much smaller than it would be in EFL or GTK, Mir support it Qt would not be a problem .i.e changes in the Qt upstream repo.

    Supporting Mir in Qt is as simple as creating a QPA plugin for it similar to the ones found here: http://qt.gitorious.org/qt/qtbase/tr...gins/platforms

    EFL and GTK+ are different in this regard though as developers from camps have expressed publicly that they are backing Wayland.

  6. #16
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,911

    Default

    Quote Originally Posted by TheOne View Post
    I read that somewhere but wasn't sure what was so special about network transparency on X beside been able to forward windows using ssh with minimal data transfer involved. And since canonical made Mir in 2 libraries I wasn't sure if the same could be achieved, but now I see is just that, 2 libraries, no networking involved.
    There's nothing REALLY special about X forwarding. Its not a new concept (not anymore anyway), X's model just has a TON of overhead, and to top it off..its synchronous. So you have two-direction network lag affecting the rendering.

    Whether or not Mir will support network transparency is up to Canonical, given the features they are lacking already... im gonna guess they dont support it now, and wont for a longtime.

    Wayland however supports rooted (full desktop) or rootless (single window) networking, its up to the client to decide that. And the system functions a lot like how VNC does, except better than VNC lol

    Check out this video: https://www.youtube.com/watch?v=RIctzAQOe44 for a rundown of X and Wayland and how they compare / contrast. Its a long video, but definitely worth watching.

    Quote Originally Posted by TheOne View Post
    That sounds like a lot hell of work
    Oh it could be. The other option would be trying to convince those toolkits to accept the Mir patches into mainline, but I really don't see that happening... MAYBE with Qt, but EFL has already said "Wayland all the way." And GTK has enough Red Hat devs that I think they could block the Mir patches from hitting mainline.

  7. #17
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote Originally Posted by jayrulez View Post
    Wrong! Qt supports Wayland. There is no public statement from of Digia or the Qt community that Mir will not be supported
    I don't think GTK+ and EFL community has said that they won't support Mir in toolkit level either (as long as Canonical does the work). Digia is definitely supporting Wayland with their Qt Compositor (a toolbox for making Qt based Wayland compositors, here's a interesting talk about it) and QtWayland efforts though.

  8. #18
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,911

    Default

    Quote Originally Posted by BO$$ View Post
    Wanna bet that Mir is the one that will be deployed first? On a very succesful linux distro that is, not on some shit that nobody will ever use.
    Being deployed really doesn't count for much if it is halfbaked and barely working. If by some miracle Canonical can get do what took Wayland 5yrs in 1 year, good for them. Get it deployed, get it some real-world testing. But I don't think Canonical's timetable will actually follow through..

  9. #19
    Join Date
    Jul 2010
    Posts
    594

    Default

    Quote Originally Posted by Ericg View Post
    If by some miracle Canonical can get do what took Wayland 5yrs in 1 year, good for them.
    It's good to note that the serious Wayland developement started in 2010 when Intel hired Kristian Høgsberg to work on it. Also a lot of the work was done elsewhere that now Ubuntu can also leverage on like removing xlib dependecies from applications, the EGL work in Mesa, splitting xkbcommon and such from X.org, writing XWayland backend for X.org (that Mir developers forked)... and so on and so forth. That being said I'm still skeptical of Canonical succeeding with their plans. The best scenario would of course be that they actually got to their senses and started using Wayland before too much damange is done and resources are lost.

  10. #20
    Join Date
    May 2010
    Posts
    173

    Default

    Quote Originally Posted by BO$$ View Post
    Wanna bet that Mir is the one that will be deployed first? On a very succesful linux distro that is, not on some shit that nobody will ever use.

    If its deployed before Wayland, then that would likely mean that they didn't take the time to think their protocol through, and that in the future it's likely going to have problems, or they are going to have to break it. And it's going to have implementation bugs too.

    All Wayland really needs AFAIK is a few DE related protocol additions, and a DE that gets ported, and a login manager. Wayland is also soon to gain subsurfaces, foreign surfaces

    If Canonical rushes with Mir, and somehow deploys it before a major distro deploys Wayland, then the odds are that Mir is going to be extremly buggy on its release, and it's going to be an inferior protocol

Posting Permissions

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