Two weeks with Mir

Tuesday, July 9th, 2013

Mir has been running smoothly on my laptop for two weeks now. It’s an all-Intel Dell XPS, so the driver stack on Ubuntu is very clean, but I’m nonetheless surprised that the system feels *smoother* than it did pre-Mir. It might be coincidence, Saucy is changing pretty fast and new versions of X and Compiz have both landed while I’ve had Mir running. But watching top suggests that both Xorg and Compiz are using less memory and fewer CPU cycles under Mir than they were with X handling the hardware directly.

Talking with the Mir team, they say others have seen the same thing, and they attribute it to more efficient buffering of requests on the way to the hardware. YMMV but it’s definitely worth trying. I have one glitch which catches me out – Chromium triggers an issue in the graphics stack which freezes the display. Pressing Alt-F1 unfreezes it (it causes Compiz to invoke something which twiddles the right bits to bring the GPU back from it’s daze). I’m told that will get sorted trivially in a coming update to the PPA.

The overall impression I have is that Mir has delivered what we hoped. Perhaps it had the advantage of being able to study what went before – SurfaceFlinger, Wayland, X – and perhaps also the advantage of looking at things through the perspective of a mobile lens, where performance and efficiency are a primary concern, but regardless, it’s lean, efficient, high quality and brings benefits even when running a legacy X stack.

We take a lot of flack for every decision we make in Ubuntu, because so many people are affected. But I remind the team – failure to act when action is needed is as much a failure as taking the wrong kind of action might be. We have a responsibility to our users to explore difficult territory. Many difficult choices in the past are the bedrock of our usefulness to a very wide audience today.

Building a graphics stack is not a decision made lightly – it’s not an afternoon’s hacking. The decision was taken based on a careful consideration of technical factors. We need a graphics stack that works reliably across a very wide range of hardware, that performs predictably, that provides a consistent quality of user experience on many different desktop environments.

Of course, there is competition out there, which we think is healthy. I believe Mir will be able to evolve faster than the competition, in part because of the key differences and choices made now. For example, rather than a rigid protocol that can only be extended, Mir provides an API. The implementation of that API can evolve over time for better performance, while it’s difficult to do the same if you are speaking a fixed protocol. We saw with X how awkward life becomes when you have a fixed legacy protocol and negotiate over extensions which themselves might be versioned. Others have articulated the technical rationale for the Mir approach better than I can, read what they have to say if you’re interested in the ways in which Mir is different, the lessons learned from other stacks, and the benefits we see from the architecture of Mir.

Providing Mir as an option is easy. Mir is a very focused part of the stack, it has far fewer tentacles and knock-on consequences for app developers than, say, the init system, which means we should be able to work with a very tight group of communities to get great performance. It’s much easier for a distro to engage with Mir than to move to SystemD, for example; instead of an impact on every package, there is a need to coordinate in just a few packages for great results. We’ve had a very positive experience working with the Qt and WebKit communities, for example, so we know those apps will absolutely fly and talk Mir natively. Good upstreams want their code widely useful, so I’ve no doubt that the relevant toolkits will take patches that provide enhanced capabilities on Mir when available. And we also know that we can deliver a high-performance X stack on Mir, which means any application that talks X, or any desktop environment that talks X, will perform just as well with Mir, and have smoother transitions in and out thanks to the system compositor capabilities that Mir provides.

On Ubuntu, we’re committed that every desktop environment perform well with Mir, either under X or directly. We didn’t press the ‘GO’ button on Mir until we were satisfied that the whole Ubuntu community, and other distributions, could easily benefit from the advantages of a leaner, cleaner graphics stack. We’re busy optimising performance for X now so that every app and every desktop environment will work really well in 13.10 under Mir, without having to make any changes. And we’re taking patches from people who want Mir to support capabilities they need for native, super-fast Mir access. Distributions should be able to provide Mir as an option for their users to experiment with very easily – the patch to X is very small (less than 500 lines). For now, if you want to try it, the easiest way to do so is via the Ubuntu PPA. It will land in 13.10 just as soon as our QA and release teams are happy that its ready for very widespread testing.

59 comments:

  1. Vincent says: (permalink)
    July 9th, 2013 at 10:09 am

    Could you provide links to those better-articulated technical rationales for the Mir approach?

  2. Fitoschido says: (permalink)
    July 9th, 2013 at 10:29 am

    I see Mir very promising — and don’t understand why the hate, and the naysaying from Kubuntu…

  3. mark says: (permalink)
    July 9th, 2013 at 10:43 am

    @Vincent, best starting point is http://blog.cooperteam.net/

  4. Sajith DIlshan says: (permalink)
    July 9th, 2013 at 10:49 am

    This article would be much more convincing if there were any benchmarking results included, which suggests that Mir indeed makes your “system *smoother* than it did pre-Mir”. Don’t get me wrong, but your words seem a bit biased when looked at from a neutral point of view.

  5. Bojan says: (permalink)
    July 9th, 2013 at 11:16 am

    Reading this it all looks good, but then again you are using Intel platform, but what about us that are using Radeon or Nvidia cards…I haven’t experienced smooth experience on any Linux distro since gnome 2. Unity, KDE, Gnome 3 or what ever DE i tried has glitches in every day use. on my Radeon card. I know that issue here is with drivers for gpu, but I hope that in near future you will make agreement with cards manufacturers to support Linux even better than now so we can have same smooth experience depend-less what card are we using.

  6. Ivan says: (permalink)
    July 9th, 2013 at 12:19 pm

    I can’t compare Mir and Wayland from technical perspective, because I know next to nothing about their internals. For me the “failure” of Wayland so far is that it takes so long to be developed. My hopes were, that Canonical would invest in it and help it move forward, but them Mir got announced. Now I hope, that one of these two alternatives will win quickly, so it would be improved and polished even further.

    Again, I can’t speak from technical perspective, but as a user, I think Mir already has the momentum. It’s impressive how fast it go that far, and with including it as a default option in 13.10 I think it has a good chance to win.

  7. Bogdan says: (permalink)
    July 9th, 2013 at 12:31 pm

    The main answer is… are you giving back to the community? Or is Mir going to be Ubuntu-only?

  8. Graham Lucking says: (permalink)
    July 9th, 2013 at 1:20 pm

    Hi mark

    I have Saucy+xmir working with Ubuntu, Xubuntu, Kubuntu, Lubuntu, & Ubuntu Studio. Ubuntu Gnome is the only hold out. When we discount the expected issues from using the development branch at such an early stage, then things are working fine.

    I have also tried Ubuntu+xmir with four alternative desktops. They install and work.

    I do not get the Chromium issue that you have and you do not mention the dualing cursors effect that is the present identification that xmir is running. But, hey, this is life at the bleeding edge.

    Regards.

  9. Jean-Yves Pellé says: (permalink)
    July 9th, 2013 at 1:21 pm

    That sounds promising. In phoronix benchmark, I saw that OpenGl via XMir is slower than Xorg. Are there some improvements planned until Saucy release ?

  10. Marc says: (permalink)
    July 9th, 2013 at 1:29 pm

    It’s surprising you find it smoother considering the performance hit pointed out here:
    http://www.phoronix.com/scan.php?page=article&item=ubuntu_xmir_benchmark&num=1

  11. alessandro simon says: (permalink)
    July 9th, 2013 at 2:24 pm

    Mark, congratulations on innovation, can not wait to try both Mir as Wayland, three is better than a (X, Mir, Wayland).
    If we listened to the Shiite world’s GNU / Linux’d still be only on the command line.
    Follow with your fight, the more aware they are on your side.

    greetings.

  12. Sam S says: (permalink)
    July 9th, 2013 at 2:39 pm

    Great job, Mark! Looking forward to Mir and Ubuntu 13.10 – anything to get improved and smoother graphics / HD video / gaming on Linux is the way to go!

    Its not about X vs Wayland vs Mir – its about what’s best for the user and the ecosystem and I think you’ve proved that again!

  13. XZezin says: (permalink)
    July 9th, 2013 at 2:41 pm

    Great to know Mir is moving along. I also keep wishing to see news regarding Ubuntu TV. I see this miriad of ARM HTPCs that run android but with a terrible touch oriented interface. Unity would do so much better on these devices!

  14. Nick says: (permalink)
    July 9th, 2013 at 3:04 pm

    Will Unity also support Wayland for us that prefer that? Or will Mir be enforced in Ubuntu?

  15. Mark Shuttleworth: soddisfatto dello sviluppo di MIR says: (permalink)
    July 9th, 2013 at 3:34 pm

    [...] stabile). Ad essere soddisfatto del nuovo MIR è anche Mark Shuttleworth il quale con un recente post sul proprio blog ha parlato dei primi quindi giorni con il nuovo server grafico installato su un DELL XPS 13 laptop [...]

  16. JP says: (permalink)
    July 9th, 2013 at 3:37 pm

    Any indication of whether or not Nvidia binary driver support for Mir will be ready in time for 13.10? It’s a must-have for those of us developing games on Ubuntu, as well as all the Steam for Linux users out there!

  17. mark says: (permalink)
    July 9th, 2013 at 3:59 pm

    Yes, that is interesting. I think it’s the difference between FPS in a game vs smoothness of a desktop. Bypass composition will bring the game FPS into line with raw performance of the GPU, so I’m not worried about that benchmark.

  18. mark says: (permalink)
    July 9th, 2013 at 4:00 pm

    Yes, of course, XMir is not yet optimised.

  19. mark says: (permalink)
    July 9th, 2013 at 4:00 pm

    @Bogdan, I think commissioning very high quality free software is an excellent contribution. It’s only our competitors that suggest we are not generous with contributions.

  20. required name says: (permalink)
    July 9th, 2013 at 4:01 pm

    Hi there.
    Congratulations on making such a difficult decision and proving it worth. I’m happy to hear that my favorite OS is in the hands of people that want to make it really better for its users. Fighting stagnation without sacrificing stability is also a difficult task and I appreciate your position about APIs.

    My only concern so far is about performance. I know that Mir is evolving very fast and that this might sound like old news, but a test conducted by Chang Liu using the Phoronix Test Suit shows that XWayland has little to no overhead when compared to X itself, often doing even better in terms of performance (which is what I’d expect from a modern display server). Other tests by Michael Larabel on Phoronix show that XMir, on the other hand, slows things down compared to X.
    I’m far from being an expert in this field (I’m really just a curious user) and I’m not sure about how much I should take those tests into consideration at this point, but I’ve got to ask: is performance being improved? Is Mir going to do better than Wayland when handling X applications, both 2D and 3D ones?

    Thank you for your time and efforts.

    Links:
    http://www.phoronix.com/scan.php?page=news_item&px=MTM5OTY
    http://www.phoronix.com/scan.php?page=article&item=ubuntu_xmir_2d&num=1
    http://www.phoronix.com/scan.php?page=article&item=ubuntu_xmir_benchmark&num=1

  21. mark says: (permalink)
    July 9th, 2013 at 4:02 pm

    @Sajith, that’s an understandable point. I think the CPU / memory performance could be benchmarked, the smoothness though is hard to quantify. Filter out my comments and try it for yourself :)

  22. pmfa says: (permalink)
    July 9th, 2013 at 5:27 pm

    Just curious, what apps did you try?

  23. Alex says: (permalink)
    July 9th, 2013 at 5:40 pm

    if you can eliminate the performance hit demonstrated in the Phoronix benchmark, and guarantee that XMir won’t break any of the wine stack (I worry about this, though admittedly without evidence at this point), I’ll be a believer.

  24. Jef Spaleta says: (permalink)
    July 9th, 2013 at 5:46 pm

    Mark,

    I’ve been asking for weeks now to get the mir build-from-source documentation updated to include the necessary information to pull the mesa and xorg branches so mir can be tested. The online documentation for Mir build from source is currently insufficient to build all the necessary bits to test mir/xmir outside of the ppa packaging. This significantly limits the ability for any externals to work with Mir at all. The bug report filed on this issues has sunk from medium to wishlist. Fix this. Make adequate build from source documetation for Mir testability by externals a priority. If you don’t nobody from another distribution is going to touch this code… Its a waste of time to attempt to test Mir with the necessary mesa/xorg patches are entirelly undocumented outside of the Ubuntu specific ppa. Fix this.

    And the working current patchset to xorg and mesa… really does need to be submitted for review and inclusion into those upstream projects for discussion with upstream. Going into production with patched xorg and mesa…without having that discussion about mergability of the patchsets with the upstream projects is…cavalier at best. But to suggest that other distributions are going to vacuum up those patches from Ubuntu, is naive.

    I very much doubt any other distribution, not dependent on Canonical packaging already, is going to touch the unmerged patchsets to enable mir/xmir in their distributions without upstream mesa and xorg blessing. And consider the politics of the situation, I fully expect that the only way any other distribution is going to be able to package a mir capable xserver is to rename it so that it can be installed side-by-side on a system with the stock xorg provided xserver. You want to see Mir/Xmir available in Debian experimental… then get those patches to mesa and xorg mainlined in those upstream projects. Stop sitting on them, and don’t wait till the last minute to send them upstream. The discussions with upstream need to be happening now….before you pull the trigger on sending Mir into default on Ubuntu.

  25. Tim says: (permalink)
    July 9th, 2013 at 6:00 pm

    @Ivan The reason why people feel that Wayland took so long to develop simply is because at the time the linux enviroment wasn’t capable of running wayland. A LOT of groundwork had to be done on toolkits, the kernel, mesa, KMS etc. to actually make wayland possible. Without this Mir wouldn’t be anywhere. That’s not coming from me that’s coming from the Mir team: http://www.youtube.com/watch?feature=player_embedded&v=h00xJwMi-eY#t=6189s
    The videos of “Mir” on 13.10 are a bit missleading especially for people who don’t understand the technical background. On 13.10 you have a fullscreen X Server running on Mir. The guy who worked on XWayland (which enables legacy X support on Wayland) now works on Mir and made some adoptions so it supports Mir and runs the whole X Desktop in the videos you saw. A real Mir desktop still is something that will take quite some time, since there is no toolkit support for it other than QtUbuntu which is used for the Phone apps. https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged Toolkit support isn’t even being worked on right now. Wayland toolkit support is more advanced in comparison. wayland.freedesktop.org/toolkits.html

  26. Cary Hartline says: (permalink)
    July 9th, 2013 at 6:16 pm

    This is absolutely wonderful. Canonical seems to be having a lot of upward momentum lately and I hope it keeps that way. Once Mir gets into place I think the office politics will slow down along with the reactionary development of the other graphics stacks.

  27. Mark Shuttleworth dice que Mir está funcionando más rápido que X says: (permalink)
    July 9th, 2013 at 6:48 pm

    [...] “Podría ser una coincidencia, pero Saucy está cambiando muy rápido y nuevas versiones de X y Compiz han sido lanzadas mientras yo estaba utilizando Mir. Pero el top sugiere que Xorg y Compiz utilizan menos memoria y menos ciclos de CPU en Mir que en el caso cuando X manejaba el hardware directamente”, dijo Mark Shuttleworth en su blog. [...]

  28. Kai Mast says: (permalink)
    July 9th, 2013 at 6:50 pm

    Just installed Mir on saucy too after reading your blogpost.

    My experience is a little different: glmark2 reports that the performance is half(!) as good as without Mir. Also I have several visual glitches, especially with textinput in firefox.

  29. mark says: (permalink)
    July 9th, 2013 at 7:14 pm

    Yes, I’m pretty sure Mir will perform just as well at first, and better over time.

  30. Ted Walther says: (permalink)
    July 9th, 2013 at 7:33 pm

    Mark, has Mir addressed the “swap access freezes my system” problem? If Firefox eats up a ton of memory and thrashes the swap partition, does Mir run smoothly despite all the block read wait states? I hate seeing one app bog down the whole desktop.

  31. mark says: (permalink)
    July 9th, 2013 at 7:55 pm

    @Kai, interesting, what chipset are you on?

  32. mark says: (permalink)
    July 9th, 2013 at 8:20 pm

    @Jef

    Nobody is ‘sitting on patches’, all of the code is public. As usual, you imply bad behaviour that isn’t present. The various patches that enable Mir are no more mysterious or hidden than patches for cutting edge subsystems anywhere else. I do expect patches will be submitted, and well-run upstreams will no doubt review them, and we’ll work to get them landed. Nevertheless, part of the review process is to kick the tires on running code, and I think it’s helpful that we have PPAs that enable just exactly that.

  33. Robert Smol says: (permalink)
    July 9th, 2013 at 8:23 pm

    To me Mir looks like ripped Wayland+Compositor. I really do not see any major technical differencies, sorry.

  34. Jef Spaleta says: (permalink)
    July 9th, 2013 at 8:27 pm

    Mark,
    Please …. pretty pretty pretty please…. get the docs at unity.ubuntu.com/mir to include the instructions on which git repository branches to pull as part of the build from source instructions so that Mir and its..patched dependencies…can be built cleanly. The instructions still continue to refer only to ppa binaries. No where in the Mir documentation lists the mesa nor the xserver git branches necessary to build/test Mir. Nowhere. And in the mailing list comms about this I’ve been pointed to no less than 3 different branch names. This needs to be documented as part of the build from source instructions. The branches necessary are in effect a “public secret” until they are adequately documented. If you need an example to aspire to, the wayland build from source instructions are pretty good.

  35. Jef Spaleta says: (permalink)
    July 9th, 2013 at 8:51 pm

    Mark,
    Let me be very clear. Building from source is part of “kicking the tires” for most of the external developers out here on the other side of the Canonical fenceline. Consuming the ppa is a non-starter. If the Mir team can’t provide the build from source instructions that include the matching mesa and xorg git branches we can’t “kick the tires”. And since you seem intent on force feeding this to users of even the alternative desktops installable from the Ubuntu repositories, there is a compelling need for externals to be able to get mir/xmir into a testable state in environments other than Ubuntu.

    I’m sure the ppa stuff is very nice for a certain subset of the Ubuntu userbase, those who are okay with potentially destablizing their mesa and xorg server to gain mir support. But I bet you a whole doughnut that that the ppa model does not serve all potential Ubuntu contributors and that some would appreciate being able to do clean /usr/local/ installs of Mir trunk and patch mesa xorg…without having to replace operational packages..and potentially destablizing their systems. You really don’t need to have to replace a stable system’s xorg to smoke test experimental Mir code if you build it entirely from source.

    But what you do need is to have the bzr and git branches for the different pieces documented and adequately communicated as part of build from source instructions. This is continues to be lacking for Mir. The build from source instructions, while they exist, do not point people to any source control branch for necessary patched mesa or xorg. Not even a diff file to apply to upstream releases is referenced. The only reference made is to the ppa and that is simply not adequate for build from source instructions. So please make sure the build from source instructions are updated so that externals can “kick the tires” a bit before the next Ubuntu release.

    Though I have to admit I find it incredibly… interesting.. that the decision to make this the default in 13.04 comes ahead of any effort to upstream the necessary patches. Confident enough to publicly state Ubuntu users are going to have rely on these patches, but not confident enough have the upstream merge discussion. Seems backwards to me. I look forward to being able to test xmir multiple monitor support as soon as it lands.

  36. Mark Shuttleworth: «Mir es mejor que la competencia» says: (permalink)
    July 9th, 2013 at 8:56 pm

    [...] no a Mir, Mir será el servidor gráfico por defecto en Ubuntu 13.10 Fuente – Mark Shuttleworth GA_googleFillSlot("468x60_ubunlog"); [...]

  37. Almeneses says: (permalink)
    July 9th, 2013 at 8:59 pm

    These are very pleasant news, personally I haven’t dared to test it yet but this has given me the impulse of being already downloading the latest daily.

    Now I have a question that concerns me a lot (and, I think, almost all laptop users): How will Mir behave with battery life? is it also being optimized?.

  38. Adam Williamson says: (permalink)
    July 9th, 2013 at 9:55 pm

    “I think the CPU / memory performance could be benchmarked, the smoothness though is hard to quantify. Filter out my comments and try it for yourself”

    It’s also something it’s virtually impossible for you to assess in an unbiased way. At the very least, you ought to test blind, though I doubt that’s possible – I expect there’s likely always some kind of ‘cue’ which indicates which you’re running somewhere.

    Unless a blinded test is possible, or some kind of objective measurement available, I don’t think it’s possible to make a reasonable judgment. People are terrible, terrible judges of this kind of thing; just look at any one of the two zillion embarrassing double-blinded tests of woo-woo audiophile crap to see what I mean. People always perceive a ‘richer, fuller sound’ and ‘better soundstage’ (it’s ALWAYS the soundstage) with the shiny new thing they just bought when they can see it’s in the circuit. Stick a blindfold on them and the story changes :)

  39. Adam Williamson says: (permalink)
    July 9th, 2013 at 9:58 pm

    Oh, and please, all commenters read Tim’s comment above:

    http://www.markshuttleworth.com/archives/1269/comment-page-1#comment-402691

    Mark is not really ‘running Mir’, exactly. He’s running his desktop on XMir: his desktop and all its apps think they’re running on an X server, they are not running as native Mir apps. Wayland has been capable of this for quite a long time.

  40. James C says: (permalink)
    July 9th, 2013 at 10:09 pm

    The biggest problem I had with the drastic change to Unity was that it felt really rushed… Especially multi-monitor behavior (which is the norm with my group of friends, family, and co-workers at least), and lack of basic configuration.

    Hopefully multi-monitor, radeon / nvidia, and switchable graphics (vgaswitcheroo / bumblebee) will be working out of the gate, otherwise it’s going to be a very painful step backwards until those things catch up.

    I also use and prefer high resolution displays these days… My retina macbook is somewhat painful with the current state of Linux graphics, hopefully Mir doesn’t follow the 100dpi assumption of the Xorg stack, with these higher resolution displays being more and more common these days.

  41. oiaohm says: (permalink)
    July 9th, 2013 at 10:09 pm

    Out performing Compiz with X11 is more than possible. Problem is early benchmarks by phoronix.com of weston vs mir has mir at a major disadvantage in performance.

    I very much suspect the major disadvantage is linked to Mir idea to go with server side management of buffers. If that is the case Mir and weston performance will never be on equal footing.

    Mark “that’s an understandable point. I think the CPU / memory performance could be benchmarked,” weston beats Mir on both of those until low memory point. Client side allocation of buffers provides some advantages.

    Xmir and Xwayland are very close to the same. The only major change is the way buffers are allocated.

    At LCA2012 there was a presentation covering how to many anything go faster on multi core systems. One of the clear things was avoid allocation management that require leaving your program to perform. Mir is currently breaking this rule. Yes buffer recycling and buffer limiting need to be performed by that kernel/driver side.

  42. Doug says: (permalink)
    July 10th, 2013 at 1:30 am

    I guess you’ve had a better 2 wk.s than many other users. Currently it seems quite unstable with unpredictable results at times & a couple of predictable but undesired. A few –

    keyboard input & cursor movement in apps, text editor, ect. ranges from ok to almost unusable, varies widely in any one session
    (like posting this reply could be ok one time, impossible the next with a 7 -10 delay per key press

    log outs take up to 10 sec’s, sometimes with random vram images, sometimes not. Shut downs are quicker but same video issues possible

    The Dash is sometimes ok, sometimes shows an image from vram instead.

    At log in sometimes processes or services keep running & or peg a core & or leak memory, ex. are plymouthd & indicator-datetime-service (currently plymouthd has graciously decided to just crash

    By far the worst is horizontal tearing in nouveau is back in spades, awful on the Desktop, awful in video playback
    But you’ve got plenty of time..

  43. oiaohm says: (permalink)
    July 10th, 2013 at 4:36 am

    Sorry I got my year wrong it is LCA2013.

    http://mirror.linux.org.au/linux.conf.au/2013/ogv/How_to_make_almost_anything_go_faster.ogv How to make (almost) anything go faster and http://mirror.linux.org.au/linux.conf.au/2013/ogv/Concurrent_Programming_is_not_so_difficult.ogv concurrent programming is not (too) difficult

    Very good videos on how to get code to run well on modern day systems. Would pay Mark to watch these then have a look at how Mir operates internally. You will find a few design ideas are counter to performance.

    Server-allocated buffers goes against concurrent programming. When running many applications it is concurrent programming that you want. So programs can go as far as possible without having to stop.

    This is where I suspect there will always be a performance difference between wayland and mir.

    Wayland will require more complex systems for take buffers back from inactive clients. Also will require a wrapper driver to hide some arm hardware nasties.

    As Mir developers said going server side buffers was going against the tide of wayland design. Its also going against the tide of how hardware mostly operates.

    There is a big risk that wayland is perfect for larger desktop hardware and mir is more suited to the more restricted. Its not like the wayland library forbids server side allocation. Doing so in wayland comes with a speed hit interesting enough weston forced server side and mir perform about the same. This is just makes me more suspect server side is only right for some cases. Possible wrong for all cases.

  44. Mir For Everyone | jonobacon@home says: (permalink)
    July 10th, 2013 at 5:43 am

    [...] today Mark Shuttleworth blogged about the evolution of Mir, the powerful display server we are building as one component in the [...]

  45. Ger Mulvey says: (permalink)
    July 10th, 2013 at 9:48 am

    Nice to see it works on all intel hardware but many people myself included would like to see you try it on say an all amd machine or a system using an nvidia gpu and tell us how good your experience is, just a thought. :)
    Ger

  46. Марк Шаттлворт опубликовал впечатления от двухнедельного использования Mir | AllUNIX.ru — Всероссийский портал о UNIX-системах says: (permalink)
    July 10th, 2013 at 11:39 am

    [...] Шаттлворт рассказал о двухнедельном использовании на своём ноутбуке [...]

  47. Клим says: (permalink)
    July 10th, 2013 at 12:57 pm

    awesome, keep up good work. hope it will be slightly simplier for end-user who doesn’t want to mess with settings and want things work out of the box.

  48. dipesh says: (permalink)
    July 10th, 2013 at 1:42 pm

    @mark

    > I do expect patches will be submitted

    Hope that is happening (means pro-active pushing patches to upstream and solving issues raised by upstream during review) more sooner then later. I am especially hoping for QMir to envolve future and find its way to upstream as first/second tier supported platform plugin. Thanks!

  49. Walid says: (permalink)
    July 10th, 2013 at 5:07 pm

    Hi Mark,

    I have used Ubuntu since Ubuntu 9.04, I love it and I still use it daily, specialy Ubuntu touch core that I am waiting to be, officialy, in the market. So about that, I like to take in mind very special ideas from “Lucas Romero Di Benedetto”: e.g, Music app for Ubuntu touch:
    “http://www.youtube.com/watch?v=UoEQIRKo8dc&list=UUV1rm9uawkHh21Cp9n_cAvg” and other ideas that you can see in his youtube channel

    PS: Sorry for my english

  50. Jonathan says: (permalink)
    July 10th, 2013 at 7:42 pm

    Hi Mark,

    any chance one or more of the Mir devs will present something at XDC2013?

  51. Open Source Pixels » Shuttleworth: Two weeks with Mir says: (permalink)
    July 10th, 2013 at 8:37 pm

    [...] Shuttleworth defends the development of the Mir display server on his blog. “Of course, there is competition out there, which we think is healthy. I believe [...]

  52. Brian says: (permalink)
    July 10th, 2013 at 10:26 pm

    Mark,

    I have been a long time supporter of Ubuntu. However, based on recent events it looks like Canonical really wants to close source ubuntu as much as possible to start delivering a product. I have faith still, but I still see no technical reason for Mir over Wayland other than complete control of the stack. I don’t mind using proprietary software however, I draw the line at the OS. I want my os to be free and open source. I can use proprietary drivers etc (I have XPS Developer Edition 13.04 running now). Is there a plan to go closed source at some point? Its clear that seems to be within the realm of possibility. Is all the Jono and your posts really FUD or are you serious about Mir having true advantages over Wayland being written by the origional X11 dev’s?

  53. celso says: (permalink)
    July 11th, 2013 at 1:43 am

    People, ler ubuntu work on mir as the way they want. everybody is able to create the software they want. In my 2 small cents, its healthy this competition (mir). since a few years back, ubuntu was the distro who wanted to inovate. why they should stop doing it now? i just would like it just still open source and more configurable.
    ( sorry for my bad english)
    i as ceptic but i am not anymore. you have my trust Mark! Good luck!

  54. LinuxLife Blog » News: Mark Shuttleworth: Zwei Wochen mit Mir says: (permalink)
    July 11th, 2013 at 2:39 am

    [...] Shuttleworth schreibt, setzt er seit zwei Wochen auf seinem Dell-Laptop, der auf Intel-Chips beruht, die aktuelle [...]

  55. mark says: (permalink)
    July 11th, 2013 at 9:42 am

    @Brian

    Mir is open source – GPL – just like pretty much everything we do.

    Mir will work with proprietary drivers, because that’s just practical reality.

    Finally, yes, I think Wayland is repeating the mistakes of X, and I would like to have a fast, lean, clean option that does not.

    Mark

  56. mark says: (permalink)
    July 11th, 2013 at 9:47 am

    @oiaohm

    Here’s some feedback from one of the lead developers of Mir:

    Firstly, we’re not doing memory allocation in the sense that you mean. We’re allocating the buffers for the client’s window; the client is free to allocate the rest of its buffers – textures, etc – however it wishes.

    Now, there *is* a context switch involved in the SwapBuffers call, but that context switch is inherent in having the display server control the output hardware. You have to switch to the display server context to present the buffer on the screen. If you want to be synchronised to vblank that also means your client needs to wait on the display server. And you always want to be synchronised to vblank.

    It’s also only one context switch per frame.

    We have additionally *chosen* to make clients who don’t wait for vblank roundtrip to Mir, but that’s not difficult to change.

    The only way you could possibly get a no-context-switch SwapBuffers is if you could give revokable pageflip privileges to a client – an extreme form of composite-bypass. This is not currently possible. There’s work happening in the drm stack around splitting modesetting privileges and rendering privileges – the rendernodes work – which may make this possible. If it does, there’s no reason we can’t support it, as it doesn’t require client allocation anyway.

    Of course, even if you remove all graphics context switches, input still requires a context switch.

  57. mark says: (permalink)
    July 11th, 2013 at 9:47 am

    Will do :)

  58. mark says: (permalink)
    July 11th, 2013 at 9:47 am

    @Almeneses

    Yes, battery life is very important to Mir, because of its relevance in the mobile push (phone and tablet).

  59. mark says: (permalink)
    July 11th, 2013 at 9:48 am

    @Robert Smol, look closer, and perhaps with a slightly more open mind ;)