Shuttleworth: Two weeks with Mir [LWN.net]

Mark 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 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."

to post comments

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 14:23 UTC (Tue) by johill (subscriber, #25196) [Link] (13 responses)

Umm, OK? What exactly is the difference between an API and a protocol?

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 14:26 UTC (Tue) by mdeslaur (subscriber, #55004) [Link] (2 responses)

Clients use a library instead of talking to the display server directly. The library has an API. The library communicates with the display server using a protocol.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 14:28 UTC (Tue) by Lukehasnoname (guest, #65152) [Link]

So there's an API and a protocol.

He's just saying that app and DE developers will "only" have to worry about the library side?

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 21:37 UTC (Tue) by mmeehan (subscriber, #72524) [Link]

So you can communicate with the display server via shared memory, for example.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 14:58 UTC (Tue) by dgm (subscriber, #49227) [Link] (9 responses)

Just the names. In an API you make calls with parameters, in a protocol you send messages with values. That's all there it is.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 15:26 UTC (Tue) by johill (subscriber, #25196) [Link] (1 responses)

Yeah that was kinda my point/thinking, I guess I should've elaborated and not just written a flippant reply. :-)

But what is he talking about then?

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 18:45 UTC (Tue) by zaitcev (guest, #761) [Link]

Remember that there's no network, it's all on the same host. Therefore, you do one apt-get update or whatever, it substitutes the library under all clients in the same time, reboot, voila - new protocol and no compatibility issues. Which is a lie but the one Mark is pushing. APIs have the same compatibility problems when poorly designed with low future resistance.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 15:27 UTC (Tue) by dgm (subscriber, #49227) [Link] (6 responses)

Self correction: there's a difference that comes from usage and convention. Protocols are for networking, and APIs for coding.

My interpretation is that they imply that Wayland defines both the API (libwayland) _and_ the socket protocol that this library exchanges with the compositor, while Mir only specifies the library calls; the socket protocol is unspecified.

Both use sockets to communicate between processes, but this is an implementation detail in Mir, while it's part of the definition of Wayland.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 15:53 UTC (Tue) by raven667 (guest, #5198) [Link] (5 responses)

I guess I'm not sure how much difference that makes as you are still tied to the library API and that design is going to fundamentally drive what the wire protocol _can_ look like, especially since what is happening under the covers with buffer management and whatever is not opaque to the window manager or application, it must have some visibility on what's going on on the other side of the protocol to work properly. Is your application compiled in 2014 going to run on the Mir server of 2024, either dynamically or statically linked? It sounds like the answer is _no_, you'll have to rebuild your application to use the new library and protocol or you will be out of luck, which is less compatibility than Wayland is trying to achieve.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 16:35 UTC (Tue) by dgm (subscriber, #49227) [Link] (4 responses)

I don't think this is a question of compatibility.

Again, the following is only my interpretation, but they key of what Canonical is doing is keeping their options open to change implementation. Why? because they are trading implementation "quality" for speed of development. They need to get it working *now*, and hope to fix any "brokenness" later. That may include specifying the protocol if that's of any use to them.

But, why I don't think this is a question of compatibility? Because I do expect that most applications will not (in the immediate future at least) talk to Wayland or Mir. There's little benefit in doing so. It's better to keep developing for ol' good X11, and let the compatibility layers do it's thing. Only high performance applications (like games or media players) and desktop shells will really benefit from directly talking Wayland or Mir.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 17:00 UTC (Tue) by raven667 (guest, #5198) [Link] (3 responses)

> I do expect that most applications will not (in the immediate future at least) talk to Wayland or Mir.

With support in the major toolkits such as GTK and Qt I would expect a large number of applications to not be running in any X11 compatibility mode but instead to be talking native Wayland (or Mir if the toolkit can support it) by default. I think Wayland will be like the Tortoise of Aesop's fables, Mir will work very hard to get something that mostly works for Unity but it will be slowly overtaken by better, more forward looking, engineering in Wayland which will be natively supported at the toolkit level by everything else.

Or maybe the zeitgeist will shift to Mir and Wayland will fall by the wayside along with Display PostScript and other technologies.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 18:10 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

> I think Wayland will be like the Tortoise of Aesop's fables

I think that Wayland is already far ahead of Mir and will probably stay that way.

> With support in the major toolkits such as GTK and Qt I would expect a large number of applications to not be running in any X11 compatibility mode but instead to be talking native Wayland (or Mir if the toolkit can support it) by default.

They may have the major toolkits, but many applications make use of X features that go beyond just the toolkits. Most devs and users are not even going to bother trying to use native versions of their applications until Wayland ships in a working form on a major distribution and it's going to take years after that to port everything over. I just don't see a huge amount of enthusiasm for porting over applications that don't have graphics being performance critical. I think that people will switch over to Wayland/mir native games and media players first, but besides that there probably won't be much of a rush.

One way or another X is going to be around for a very long time and probably for a couple years after Wayland starts being used widely X will continue to be the primary use case for Wayland.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 22:44 UTC (Wed) by rahvin (guest, #16953) [Link] (1 responses)

I agree, older stable apps will stay with X, newer applications developed after Wayland is fully developed _and_ deployed may end up Wayland only but only masochists would go back and rewrite stable applications to Wayland without a good reason (performance or otherwise).

If fact I thought the developers were pretty clear that they believe X would be around for a long time after Wayland is in use.

Shuttleworth: Two weeks with Mir

Posted Jul 11, 2013 3:07 UTC (Thu) by raven667 (guest, #5198) [Link]

I don't see the likelihood of Wayland-only applications as applications are written with toolkits and these are often multi-platform. I don't think many applications are so tied to X11 that they won't be easily modified to run on Wayland natively, it will be much less work than porting to Windows or MacOSX which many apps already run on.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 14:36 UTC (Tue) by AndreE (guest, #60148) [Link] (13 responses)

I am certainly not an Ubuntu basher, but the biggest fallacy of this statement is that "others have articulated the technical rationale" for Mir. If he is referring to his own developers posts, all they basically articulated was their lack of understanding about Wayland.

It also seems quite odd that he is trying to promote this as a technical decision, only to say that he can't (or won't) really outline the technical rationale, apart from the vague buzzwords of rapid evolution and quality user experience, etc. etc.

In any case, it will interesting to see how Mir turns out, but inertia and the weight of numbers and experience appear to be against them

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 16:42 UTC (Tue) by drag (guest, #31333) [Link] (1 responses)

I am satisfied that the X developers have learned enough from trying to improve X for enough decades that they will not only be likely to avoid the same pitfalls that they ran into with X, but know enough about the direction of modern hardware that their Wayland display server will be fairly future-proof.

With Mir, I don't see the same level of diverse expertise.

Maybe it will do well, maybe not.

One thing though: Canonical is a hell of a lot better on the propaganda then the Wayland/X folks are. It would probably be useful at this point to getting a workable XWayland implementation put together so that users can see how well it's going to work.

X isn't going to go anywhere anytime soon and because of this almost all applications people are going to use on Wayland or Mir are going to be X apps. So the primary use case for people moving to Wayland is X Windows and general X performance and compatibility going to be a VERY valid comparison between the two display servers. Maybe more valid of a comparison then any other one you'd care to make. At least for the next few years.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 9:32 UTC (Wed) by ovitters (guest, #27950) [Link]

There are various applications which use a toolkit, but still sometimes make an X call. Porting those to Wayland should be relatively easy and then Canonical can claim that they've ensured that they work on Mir too :P

For required expertise, Mir and Wayland seem pretty related. A lot of code in Mir seems to be taken from things that were meant for Mir. As Wayland developers fix the infrastructural changes, I assume it'll benefit Mir as well.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 17:13 UTC (Tue) by jdulaney (subscriber, #83672) [Link] (10 responses)

Speaking with one former Canonical dev (who worked on X), he did state that a lot of the decision stems from unresponsiveness of Wayland devs.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 19:04 UTC (Tue) by simosx (guest, #24338) [Link] (4 responses)

> Speaking with one former Canonical dev (who worked on X), he did state that a lot of the decision stems from unresponsiveness of Wayland devs.

I think that is an important point, and I believe it is genuine.

My view is that from the Wayland camp (and before, from the GNOME camp) there were developers that viewed anything Ubuntu-related in a negative light. Whether this unresponsiveness is partially related to their negativity, is something that needs investigation.

There is an alarming trend in free software development that not being nice is something good. Have a look at Zemlin's talk, http://www.linux.com/news/featured-blogs/185-jennifer-clo... who claims that flaming and not being civil is something that helps. I hope this moronic view is resolved at some point in the future. It is similar to the view that we need a war in order to get great technological advancement (for example, WW 2 for the atomic bomb).

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 9:17 UTC (Wed) by ovitters (guest, #27950) [Link] (2 responses)

So quick to believe something negative about Wayland, even when it is totally not true. Canonical never contacted Wayland developers. Don't you remember the utter surprise after the Mir announcement?

One Wayland developer contacted a Mir developer during the secret period, the response was "I am working on something else, Wayland is less of a priority".

Attributing the whole mess to Wayland is rich.

Shuttleworth: Two weeks with Mir

Posted Jul 11, 2013 0:39 UTC (Thu) by FranTaylor (guest, #80190) [Link] (1 responses)

> Attributing the whole mess to Wayland is rich.

Calling this a "whole mess" is JUST AS RICH

Yes indeed we actually have a chance for LEGITIMATE COMPETITION in the desktop arena. For 30+ years there has been STAGNATION in X windows, now there is competition, and you call it a "whole mess"

I for one am looking forward to great desktop progress now that we can actually HAVE conversations about what is better and what is worse. And YOU think this is a MESS! UNREAL!!!

If someone dropped a bundle of cash in your lap, you would complain about the weight.

Shuttleworth: Two weeks with Mir

Posted Jul 11, 2013 8:22 UTC (Thu) by anselm (subscriber, #2796) [Link]

We have had »legitimate competition in the desktop arena« for 15 years now (e.g., KDE versus GNOME), and look where that got us. One person's »competition« is the next person's »fragmentation«.

Also, if you really believe that X has »stagnated« for thirty years, you must have hidden under a rock for the last ten or so of those. There used to be a time when nobody was doing much at all but we have come a long way since then, thanks to people like Keith Packard.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 10:24 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

Being not nice is sometimes good. Being nice has costs, as well as benefits; sometimes, the balance is such that being not nice is the better plan. One can, of course, quite fairly claim that the balance point isn't where certain high-profile FOSS participants judge it to be.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 19:15 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

So an unnamed Canonical employee talks to you off the record about some off the record conversations that went nowhere? Gee well...meh. Nothing like a little unverifiable personal interactions to really clear up where the miscommunication happened.

unresponsiveness in what context? IRC? conferences? bugzilla? private email?
mailinglist? Where exactly did a Canonical employee raise a concern that was not attended to? If it happened in private comms or in an archived discussion forum, there's really no good reason to bring it up into a publicly archived discussion now.

And considering that Canonical was working on this for something like 8 months behind closed doors, I'm really not inclined to entertain this argument. I've seen precious little evidence that Canonical engaged at all in public discussion concerning technical requirements as they perceived them. So please point me to the archived discussion that supports unresponsiveness to a Canonical concern specifically _before_ Mir development was started.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 9:15 UTC (Wed) by ovitters (guest, #27950) [Link]

Various Wayland developers stated publicly (Google+) that Canonical never contacted them about the issues they had. I've seen a comment from a Mir developer (GNOME related blog) who said that they didn't contact Wayland, there just was a decision and they had to follow.

I'm calling bullshit on what you're suggestion. Please back up your statements, don't be vague.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 9:49 UTC (Wed) by dgm (subscriber, #49227) [Link]

I seriously doubt it. But in any case, can you ask your source to point specific examples of such unresponsiveness? After all, the wayland-devel mailing list http://lists.freedesktop.org/archives/wayland-devel/ is openly accessible.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 19:13 UTC (Wed) by Zizzle (guest, #67739) [Link] (1 responses)

Yeah I can just picture it.

"Wayland guys, Canonical here, can you guys just hurry up and finish Wayland for 13.04 and make it work on phones as well. We will help by lending you this used handkerchief. K thx bye."

*crickets*

"Look at how unresponsive these Wayland jerks are".

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 23:47 UTC (Wed) by hummassa (guest, #307) [Link]

> "Wayland guys, Canonical here, can you guys just hurry up and finish Wayland for 13.04 and make it work on phones as well. We will help by giving you a trillion bazillion dollars. K thx bye."

There, I fixed it for you.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 15:15 UTC (Tue) by heijo (guest, #88363) [Link] (4 responses)

The Mir protocol still seems to only be this:

service DisplayServer {
  // Platform independent requests
  rpc connect(ConnectParameters) returns (Connection);
  rpc disconnect(Void) returns (Void);
  rpc create_surface(SurfaceParameters) returns (Surface);
  rpc next_buffer(SurfaceId) returns (Buffer);
  rpc release_surface(SurfaceId) returns (Void);

  // Platform specific requests
  rpc drm_auth_magic(DRMMagic) returns (DRMAuthMagicStatus);

  rpc test_file_descriptors(Void) returns (Buffer);

  rpc configure_surface(SurfaceSetting) returns (SurfaceSetting);
}

Can anyone explain how this toy protocol can support input (keyboard, mouse, multicursor, gamepad, multitouch, gesture), getting the screen DPI, subpixel layout, multimonitor layout, resizing windows, moving windows, writing panels and so on?

Not to mention where the innovation is compared to X with DRI2 or Wayland?

Or perhaps this thing is just intended as a screen output abstraction to run X on either Android or a DRM driver?

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 12:21 UTC (Wed) by pboddie (guest, #50784) [Link]

That looks like a subset of SDL. Hey, I wonder if anyone has made Xorg run on top of SDL.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 22:54 UTC (Wed) by rahvin (guest, #16953) [Link] (2 responses)

It was my understanding (I haven't looked at the code to be sure) that Mir is simply a modified Android SurfaceFlinger display server. I believe you can see that in the code.

Now you get to wonder if such a simple display server has a valid use on a desktop but you need to contend with Shuttleworth's view that the desktop is dead and we are all going to be working on phones and tablets in the future. IMO he drank the koolaid and believes general computers are dead.

Shuttleworth: Two weeks with Mir

Posted Jul 12, 2013 21:48 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

He thinks that?!

That's... stunning. Obviously RSI has never afflicted him, or he'd never think that for a second. (For that matter, obviously he's never tried to write large amounts of text, or create large amounts of *anything* other than unedited video, on a phone or tablet.)

Shuttleworth: Two weeks with Mir

Posted Jul 12, 2013 22:36 UTC (Fri) by dlang (guest, #313) [Link]

I don't think he has said that, but a lot of people are reading that meaning into the Gnome 3 and Unity UI designs that feel much more like a tablet UI than a desktop UI

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 15:49 UTC (Tue) by Zizzle (guest, #67739) [Link] (10 responses)

A few questions spring to mind:

a) are any apps going to use Mir natively in 13.10 or is Mir just another layer in the X stack? i.e. XMir is what the applications will be really talking to

b) Performance is better? If it's an additional layer, I don't see how.

Phoronix also didn't measure any.

http://www.phoronix.com/scan.php?page=article&item=ub...

c) Haven't most of the community Ubuntu forks and KDE said they won't support Mir?

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 15:56 UTC (Tue) by raven667 (guest, #5198) [Link] (4 responses)

Actually if each app gets its own X server then performance could be better in areas where a single X server would be a bottleneck or cause resource contention between applications. You wouldn't see any benefit though and additional resource usage, on the low end where there is no contention.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 15:59 UTC (Tue) by raven667 (guest, #5198) [Link] (2 responses)

I should have read the link first, the only thing Phoronix tested were full-screen 3D games, applications which almost entirely bypass the X server anyway, not anything that would stress the X protocol or show a difference in application performance.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 16:02 UTC (Tue) by Zizzle (guest, #67739) [Link] (1 responses)

Yeah, good point, but the 2D ones here don't look great either:

http://www.phoronix.com/scan.php?page=article&item=ub...

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 16:12 UTC (Tue) by raven667 (guest, #5198) [Link]

Yeah, I see. What'd be good would be to run a number of those tests in parallel, up to say double the number of cores in the test machine, to try and engineer contention for X resources.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 17:30 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Each app runs on the same X server. The entire session is run under XMir.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 3:49 UTC (Wed) by jke (guest, #88998) [Link] (4 responses)

> c) Haven't most of the community Ubuntu forks and KDE said they won't support Mir?

I doubt many projects would reject reasonable patches to add support. If Canonical were to send some, that is.

If you want to do something with big sweeping changes, you got to get into the upstreams. For example, there were lots of patches coming from the Red Hat side to add Systemd unit files to many projects. Red Hat has been rather consistent in that way. When they want to do something, patches are sent to the relevant upstreams.

If Canonical wants stuff to happen around Mir they need to take the "patches are welcome" motto to heart.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 10:05 UTC (Wed) by ovitters (guest, #27950) [Link] (2 responses)

Gtk+ maintainers mentioned already that a patch providing Mir support is welcome, provided that Canonical does more than just a one-off patch. It needs to handle the bugreport and maintenance as well.

Note that due to Mir being distribution-specific, gtk+ maintainers are unable to do any good review on the code itself, nor handle bugreports. Seems obvious, but often overlooked.

Unity is supposed to be using Qt and have never seen that they have added Mir support to gtk+, but maybe that's hidden somewhere.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 16:00 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (1 responses)

Is there a citable reference from a mailinglist or blog where the original "patches are welcome" statement was made?

-jef

Shuttleworth: Two weeks with Mir

Posted Jul 14, 2013 11:38 UTC (Sun) by maxiaojun (guest, #91482) [Link]

https://mail.gnome.org/archives/gtk-devel-list/2013-June/...

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 19:16 UTC (Wed) by Zizzle (guest, #67739) [Link]

http://www.muktware.com/5353/kdes-kwin-wont-support-ubunt...

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 16:00 UTC (Tue) by shmerl (guest, #65921) [Link] (12 responses)

Since there is no stable protocol, nobody is going to use Mir, since nobody wants things to break miserably every time Mir decides to change something. So it can evolve faster, yeah. Exactly because there will be no users outside Ubuntu. May be that was their whole point to begin with.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 16:49 UTC (Tue) by dgm (subscriber, #49227) [Link] (4 responses)

You're mixing things up. Since there's no stable protocol, it's clear that nobody is going to be _developing_ applications that talk this protocol. But they probably weren't anyway, so it makes hardly a difference.

But, there are going to be a few people _using_ Mir. Those installing the next Ubuntu will. And if it gives an smooth X11 experience (or even just an acceptable X11 experience) they are going to keep it. Those for whom Mir fails will not, of course, but I don't think it's going to be everybody.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 16:52 UTC (Tue) by shmerl (guest, #65921) [Link] (3 responses)

Yes, that's what I meant above, when I mentioned "outside Ubuntu". I.e. basically other distributions and desktop environments won't be interested in Mir, which lacks any commitment regarding the protocol or even the API.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 0:09 UTC (Wed) by zyga (subscriber, #81533) [Link] (2 responses)

Is there any statement about API stability? IMHO the whole point of ignoring protocol stability is because of API stability (so you can keep calling the same function but it will send smarter stuff over the wire with the next libmir* revision)

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 9:40 UTC (Wed) by dgm (subscriber, #49227) [Link] (1 responses)

That's a very good question, and AFAIK the answer is "no".

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 15:12 UTC (Wed) by dlang (guest, #313) [Link]

Actually, I read the statements to be an implicit "yes"

I haven't seen a formal statement along the lines of "the API for the Mir Client library will always be backwards compatible", but everything else in the way that they talk about how the library is used, and why they are standardizing on the library instead of the interface protocol says that they expect the library interface to be stable.

In fact, now that I am thinking about it, I do think I've seen comments in a FAQ post where the question is something like "will you be able to run 2013 Mir apps in 2020 Mir systems" and the answer was along the lines of "yes, the compatibility is provided by the library"

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 18:19 UTC (Tue) by dlang (guest, #313) [Link] (5 responses)

I'll point out that ALSA doesn't have a fixed protocol, it has a fixed API to it's client library. The protocol that the library uses to talk to the kernel changes from version to version.

Mir is doing the same thing. Instead of defining a fixed interface to the Mir server, they are defining a fixed library interface to use. As the Mir server changes it's internal implementation, the library will change to match the Mir server.

As long as applications don't statically include the Mir client library, they will remain compatible in the future, just like ALSA apps.

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 18:51 UTC (Tue) by shmerl (guest, #65921) [Link] (1 responses)

If they pledge to respect API compatibility, that could improve things.

Shuttleworth: Two weeks with Mir

Posted Jul 11, 2013 0:42 UTC (Thu) by FranTaylor (guest, #80190) [Link]

In other words, if they bake in their bad decisions BEFORE they have had a chance to understand their impact, yeah that's a GREAT way to design something new.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 6:37 UTC (Wed) by cladisch (✭ supporter ✭, #50193) [Link]

> I'll point out that ALSA doesn't have a fixed protocol, it has a fixed API to it's client library. The protocol that the library uses to talk to the kernel changes from version to version.

However, the usual kernel API guarantees apply; so far, all changes have been backwards compatible.

What the separate client library turned out to be useful for is the ability to implement ALSA devices outside of the kernel, i.e., filter drivers like sample rate conversion or software mixing, or devices using other kernel APIs like Bluetooth or OSS.

I don't know if the same applies to Mir, i.e., if it would possible to emulate the Mir API on top of Wayland or X.

Shuttleworth: Two weeks with Mir

Posted Jul 11, 2013 1:51 UTC (Thu) by rich0 (guest, #55509) [Link] (1 responses)

Well, unless they make the client library compatible with all past versions of the server I can see a BIG problem with this design - remote displays.

Sure, applications tend to link to toolkits - they don't talk X11 over the network to the server. However, the toolkit DOES need to know how to talk X11 over the network, and if the protocol changes ever two weeks that gets MUCH harder to implement.

If they don't provide backwards compatibility then an application will only be able to be displayed on a display whose version matches the client lib in use. That of course works for 99% of the Ubuntu use cases, but breaks a fundamental feature of X11 - remote displays.

Shuttleworth: Two weeks with Mir

Posted Jul 11, 2013 2:18 UTC (Thu) by dlang (guest, #313) [Link]

Mir and Wayland don't support remote displays

XMir doesn't need the backwards library compatibility because it's X that's the remote protocol, not anything the Mir library implements.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 15:40 UTC (Wed) by tjc (guest, #137) [Link]

So it can evolve faster, yeah. Exactly because there will be no users outside Ubuntu. May be that was their whole point to begin with.

I think that's more or less their thinking. Example:

Where the Wayland libraries are all about IPC, Mir is about producing a library to do the drudge work of a display-server-compositor-thing, so in this way it's more like Xorg than Wayland. In fact, it's a bit more specific - Mir is about creating a library to make the most awesome Unity display-server-compositor-thingy. We're not aiming to satisfy anyone's requirements but our own. That said, our requirements aren't likely to be hugely specific, so Mir will likely be generally useful.
To some extent this is why GNOME and KDE aren't amazingly enthused about Mir. They already have a fair bit of work invested in their own Wayland compositors, so a library to build display-server-compositor-thingies on isn't hugely valuable to them. Right now.

Perhaps we'll become so awesome that it'll make sense for GNOME or KDE to rebase their compositors on Mir, but that's a long way away.

blog.cooperteam.net

Shuttleworth: Two weeks with Mir

Posted Jul 9, 2013 19:21 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (3 responses)

I perceive the blog as a satisfaction statement about Mir's development. It describes how easy it was to port to Mir mayor graphical libraries and how smoothly everything works. If it defends anything, then it is a decision to stick with upstart rather than switching to systemd.

It is like stating that Google had to defend the decision to use non-X11 graphics on a Linux platform (Android) or to develop own "crippled" version of X-server (Chromebook) while pointing to blogs where they just showed cased the technologies.

Shuttleworth: Two weeks with Mir

Posted Jul 10, 2013 12:03 UTC (Wed) by hunger (subscriber, #36242) [Link] (2 responses)

Xmir is a xorg xserver running on top of mir. So basically all the blog post was about is that the xorg server can run X apps very well, even when using a strange "graphics card" that is actually a mir server.

That is no small feast and demonstrates that the mir server can hardle full screen applications well by now (both the rendering part as well as input handling). But it is far from showing how easy (or hard) it is to port applications or toolkits to the mir server.

Shuttleworth: Two weeks with Mir

Posted Jul 11, 2013 0:58 UTC (Thu) by FranTaylor (guest, #80190) [Link] (1 responses)

> But it is far from showing how easy (or hard) it is to port applications or toolkits to the mir server.

Welcome to 2013, where Linux and Solaris and IOS and Windows and Android all have market share and any decent application is ALREADY going to be display-agnostic.

Who has bare X11 API calls in their application anymore? Huh? Any substantial application is going to be written on a toolkit like Qt and all display issues are handled under the covers.

Really the only "apps" that need to be ported to mir are the toolkits, and this is already done. If you have made the poor decision to hard-code your display code then you can always look at Qt source (yay for open source) and see how they did it.

And BESIDES all that, X11 integration is a FREAKING NIGHTMARE. You're not drawing on a display, you are talking over the network, and it's painful. The semantics are beyond bizarre. Have you even tried to comprehend ICCCM? If you can get your app to work correctly on X11 then any other display system should be a walk in the park.

Shuttleworth: Two weeks with Mir

Posted Jul 11, 2013 8:50 UTC (Thu) by hunger (subscriber, #36242) [Link]

> Really the only "apps" that need to be ported to mir are the toolkits, and this is already done.

I am aware that most apps use toolkits nowadays, but I have not seen any evidence of them being ported yet. I would love to take a look at the patch sets enabling mir support in Qt or Gtk, but have not been able to find either so far. Maybe you can point me to the right repositories?

Please note that there was no mention of running anything "native" on mir in the blog post, or at least I could not spot any reference.

> And BESIDES all that, X11 integration is a FREAKING NIGHTMARE.

Yeap, which is why I am impressed by that setup working for 2 weeks:-)

> You're not drawing on a display, you are talking over the network

But all that nastiness is handled by the Xserver built into xmir. All mir has to do itself is take the pixmap produced by that server and put it onto the screen (and of course forward all input events to the X server). That is actually a pretty simple task.

The tricky part is having several applications sharing the mir server at the same time: That is where it becomes hard to decide where to send events to, etc. I have not seen anybody making the claim that this works reliably yet.

Shuttleworth: Two weeks with Mir

Posted Jul 14, 2013 11:59 UTC (Sun) by maxiaojun (guest, #91482) [Link] (3 responses)

I don't know much about Mir.

For Wayland, it is probably sufficient for a phone (yet to see). But it could really cause a wave of disaster on desktop. This is not because of any technical issues (as no one is really using it). This is due to the way brilliant jerks in the so-called community do things.

Shuttleworth: Two weeks with Mir

Posted Jul 14, 2013 13:54 UTC (Sun) by BlueLightning (subscriber, #38978) [Link] (2 responses)

Sounds like you don't know much about Wayland either.

Shuttleworth: Two weeks with Mir

Posted Jul 14, 2013 14:33 UTC (Sun) by maxiaojun (guest, #91482) [Link] (1 responses)

Yet to see working Wayland compositors beyond Weston. And how compositors from different parties be compatible with each other.

Shuttleworth: Two weeks with Mir

Posted Jul 15, 2013 10:29 UTC (Mon) by renox (guest, #23785) [Link]

>And how compositors from different parties be compatible with each other.

While in theory, this could be an issue, there is nothing magical about X which make KDE's applications working in Gnome (for example): the reason why this kind of things work (most of the time) is because their developers care about it and do the necessary work, I see no reason why this would be different over Wayland instead of X.