Announcement

Collapse
No announcement yet.

Mir Display Server Now Supports VT Switching

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

  • Mir Display Server Now Supports VT Switching

    Phoronix: Mir Display Server Now Supports VT Switching

    While there was the video of Unity Next running on Mir with a Google Nexus 4 hand-held, in terms of the overall feature completeness of the Mir Display Server, there is still much work ahead. Only on Friday did Mir even gain support for switching to virtual terminals...

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

  • #2
    Originally posted by BO$$ View Post
    Go Mir! Kill Wayland! There can be only one! Go Canonical Go! We need more initiatives like these to show the losers how it's done!
    I hope this is sarcastic. If not, this isn't some new Mir innovation, this is extremely basic functionality that has been missing from Mir (like most basic Mir functionality not provided by forks of third-party libraries).

    And did you miss the second part of the post where it was pointed out that Mir's only claim to fame (android support) was actually provided by a third-party library developed for wayland?
    Last edited by TheBlackCat; 04-13-2013, 07:43 AM.

    Comment


    • #3
      Originally posted by BO$$ View Post
      Go Mir! Kill Wayland! There can be only one! Go Canonical Go! We need more initiatives like these to show the losers how it's done!
      Are you high right now? Your comments are extremely polarized, to the point where it is either laughable.

      Comment


      • #4
        FLOSS will not kill PR nor will it kill POLITICS.

        libhybris become victim of those. Canonical wanted their work on non-Wayland successor to be not known to anyone outside Canonical. For sure they could not start to contribute to libhybris, cause someone would notice it and would wonder why they do it! And most probably we would see some black PR thrown at Canonical for developing things their current user do not use while not developing anything their users use. Keeping it silent and separate was OK. Keeping it separate after anouncment would be not. So Canonical devs performed as well as we could expect them to.

        Comment


        • #5
          Originally posted by przemoli View Post
          libhybris become victim of those. Canonical wanted their work on non-Wayland successor to be not known to anyone outside Canonical. For sure they could not start to contribute to libhybris, cause someone would notice it and would wonder why they do it! And most probably we would see some black PR thrown at Canonical for developing things their current user do not use while not developing anything their users use. Keeping it silent and separate was OK. Keeping it separate after anouncment would be not. So Canonical devs performed as well as we could expect them to.
          Your argument simply doesn't make any sense. I don't believe that Canonical has ever had as bad public backlash as they have had with Mir and the libhybris mess isn't making it any better. They could have also worked on libhybris without giving anything other away than the fact that they are working mobile devices... which we already knew because they had publicly announced that a long time ago. It's very unfortunate that Canonical seems to be incapable of taking part in collaborative developement process.

          Comment


          • #6
            @BO$$ LOL. You are not writing properly your /sarcasm tags, though.

            Comment


            • #7
              Originally posted by przemoli View Post
              libhybris become victim of those. Canonical wanted their work on non-Wayland successor to be not known to anyone outside Canonical. For sure they could not start to contribute to libhybris, cause someone would notice it and would wonder why they do it! And most probably we would see some black PR thrown at Canonical for developing things their current user do not use while not developing anything their users use. Keeping it silent and separate was OK. Keeping it separate after anouncment would be not. So Canonical devs performed as well as we could expect them to.
              Considering Canonical had already promised support for wayland, making improvements to a library intended for use by wayland would probably not have been all that surprising.

              Wait, this is Canonical we are talking about. I guess if they suddenly started contributing to upstream projects it would have been surprising </snark>

              Comment


              • #8
                Originally posted by Alejandro Nova View Post
                @BO$$ LOL. You are not writing properly your /sarcasm tags, though.
                Why are you talking to a troll

                Comment


                • #9
                  Originally posted by BO$$ View Post
                  Go Mir! Kill Wayland! There can be only one! Go Canonical Go! We need more initiatives like these to show the losers how it's done!
                  Rooting for Mir to beat Wayland is like rooting for the Russians to beat the USA to the moon in 2013. Wayland already won.

                  Weston supported something as simple as VT switching for years, and Xorg before that. It's not an innovative feature at all, in fact, when I tested Mir a while ago, I laughed at the fact that when I started it, and tried to switch TTYs, it would hijack the TTY, and not stay confined to the TTY I started it in, despite it being 9 months old... This article is more or less news that Mir hasn't been supporting such a feature UNTIL NOW!

                  Mir is FAR behind Wayland. Grab a Wayland Live CD, and try a MIR PPA, and then find out which one is leading the way.

                  Hint: It's the one that's not Mir

                  Comment


                  • #10
                    Client/Server

                    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?

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        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

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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.

                            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

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X