Announcement

Collapse
No announcement yet.

Mir 0.20 Ships With Screencasting To Virtual Output Support

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

  • Mir 0.20 Ships With Screencasting To Virtual Output Support

    Phoronix: Mir 0.20 Ships With Screencasting To Virtual Output Support

    Canonical developers have put out version 0.20 of Mir in time for the next OTA update for Ubuntu Phones...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I wonder how it works with newer phones these days. My S3(exynos) and Tab4(snapdragon400) could barely cast 720p30 and that was with dropped frames here and there. Now I have Honor 4x(kirin620) which is even worse.

    Comment


    • #3
      A Dutch article tried it: http://tweakers.net/reviews/4399/ubu...onaliteit.html (run it through Google translate)

      A Nexus 4 is too slow. An M10 with a Mediatek MT8163 chipset + 2GB of memory is mostly fluent (not perfect). They tried Miracast, but was too slow. In the comments people note that it was partly due to the lack of compression. Not sure if they were running this OTA version already. Comments mention it'll take until OTA version 10 until it will be smooth.

      Comment


      • #4
        BQ Aquaris M10 has a chipset capable of 1080p output, but proper support needs to be implemented in the OS, probably with OTA-10. Current Ubuntu phones will likely need compression to make it smooth.

        Comment


        • #5
          There a software for Linux and/or Windows to turn a PC into a Miracast reciever? I would like to try it with my Nexus4 but I don't have a compatible TV.

          Comment


          • #6
            Originally posted by blindfrog View Post
            I wonder how it works with newer phones these days. My S3(exynos) and Tab4(snapdragon400) could barely cast 720p30 and that was with dropped frames here and there. Now I have Honor 4x(kirin620) which is even worse.
            It's unfortunate, but it's going to be very much hit-and-miss for a few years.

            The various silicon vendors all implement ARM processors as designed by ARM, but they differentiate their product on other components such as codecs and networking and all the associated buses and interconnects. To get smooth broadcast video, you need to get hardware encoding and colour conversion using zero-copy techniques (hopefully supported by optional off-bus FIFOs between coprocessors) coupled with low-latency networking, and it all has to be recognized and controlled all the way up through the software stack from the kernel to userspace and back. All this is going on while applications are running on the CPU contending for the bus and generating more frames. Unlike the PC world, every phone is different and needs some level of tweaking of the software stack to get full throughput. Different vendors offer different levels of technical support for this kind of thing: most of them offer the "cold shoulder" level of support.

            Interestingly, this is one of the reasons Canonical chose to pursue Mir instead of Wayland: at the time the design of Wayland precluded the use of the server-side hardware buffer pipelining required to do this kind of thing.

            Comment


            • #7
              Originally posted by Julius View Post
              There a software for Linux and/or Windows to turn a PC into a Miracast reciever? I would like to try it with my Nexus4 but I don't have a compatible TV.
              No clue, but maybe buy one of of the Miracast receivers? It just needs HDMI and USB. So you'd maybe even could put it into your monitor. I'd probably buy the Microsoft one (fun to use MS to improve Linux): https://www.microsoft.com/accessorie...pter/cg4-00001 Though checking the compatibility, the MS receiver only works with MS phones, not any Android!

              Whatever you buy, can still resell once you're done.

              Comment


              • #8
                Originally posted by bregma View Post
                Interestingly, this is one of the reasons Canonical chose to pursue Mir instead of Wayland: at the time the design of Wayland precluded the use of the server-side hardware buffer pipelining required to do this kind of thing.
                This has been debunked by the Wayland developers many times, indeed, Wayland actually shipped on phones prior to Ubuntu and is far more successful on embedded hardware already than Mir is. Here is Kristian Høgsberg's response from 2013 on LWN, to this nonsense that you and others are still perpetuating now in 2016:

                Originally posted by Kristian Høgsberg
                Client side buffer allocation refers to how the client allocates its own pixel buffers directly from the kernel memory manager instead of going through the server. It's an implementation detail in the mesa side of Wayland and it's not something we ever really made a big point about. It's all covered by the wl_drm interface, which is private to mesa, defined in mesa and not part of core wayland. Other driver stacks would define their own wl_$chipset interface and allocate and exchange buffers whereever and however they want/need to.

                And it's not a matter of "Wayland adding support" for server side buffers. It's not a feature in itself, it typically means that your hw or driver has restrictions on which process can allocate memory. The misconception here was that because the mesa integration code allocates buffer client side, other drivers wouldn't be able to allocate through the server.
                The reality is that Mir's existence still remains irrational in light of all evidence, both at the time of it's introduction, as well as today. Even if there were some technical reasoning (which all evidence and code indicates there isn't), it would still have made far more sense to make an extension to the Wayland protocol, than to just reinvent the wheel for the sake of reinventing the wheel. Even the "licensing" argument makes no sense, given that Mir has a more restrictive license than Wayland's BSD/X11/MIT-style permissive license.

                Comment


                • #9
                  Originally posted by azari View Post
                  This has been debunked by the Wayland developers many times, indeed, Wayland actually shipped on phones prior to Ubuntu and is far more successful on embedded hardware already than Mir is.
                  I'd love to see a demonstration of Miracast from a Wayland phone. Where can I buy one with that functionality?
                  Here is Kristian Høgsberg's response from 2013 on LWN, to this nonsense that you and others are still perpetuating now in 2016:
                  Well, render buffer allocation is irrelevant to the frame post-processing required for Miracast, so that quote is hardly relevant.
                  The reality is that Mir's existence still remains irrational in light of all evidence, both at the time of it's introduction, as well as today. Even if there were some technical reasoning (which all evidence and code indicates there isn't), it would still have made far more sense to make an extension to the Wayland protocol, than to just reinvent the wheel for the sake of reinventing the wheel. Even the "licensing" argument makes no sense, given that Mir has a more restrictive license than Wayland's BSD/X11/MIT-style permissive license.
                  Thankfully, your understanding or permission is not a prerequisite for the continuing success of the Mir display server.

                  As for licensing, Canonical licenses its software using the GPLv3 to ensure it stays free for everyone. The same can definitely not be said about using a BSD-style license which allows anyone to take your software and make an Android-style proprietary fork without releasing code. The distribution license difference is very very significant.

                  Comment


                  • #10
                    Originally posted by bregma View Post
                    Well, render buffer allocation is irrelevant to the frame post-processing required for Miracast, so that quote is hardly relevant.
                    That's still not a clear answer.

                    Could Wayland have been used yes or no? Please also consider the amount of time spend on Mir. Meaning: with the same amount of development time that was put in, would you be around the same stage as now with Mir?

                    Your license argument is something new, so assume Mir is still pointless.

                    Comment

                    Working...
                    X