User: Password:
|
|
Subscribe / Log in / New account

Ubuntu unveils its next-generation shell and display server

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

By Nathan Willis
March 6, 2013

Ubuntu publicly announced its plan for the future of its Unity graphical shell on March 4, a plan that includes a new compositing window manager designed to run on the distribution's device platforms as well as on desktop systems. The plan will reimplement the Unity shell in Qt and replace Compiz with a new display stack called Mir that will incorporate a compositor, input manager, and several other pieces. Mir is not designed to use the Wayland display protocol (although the Ubuntu specification suggests it could be added later), a decision that raised the ire of developers in several other projects.

Announcements, announcements, announcements

Oliver Ries made the announcement on the ubuntu-devel mailing list, saying it was timed to coincide with the start of the distribution's Ubuntu Developer Summit, where more detail and discussion would follow. Ries said the changes were necessary "in order to implement the vision of converged devices"—namely the Ubuntu Touch project to build an interface compatible with phones, tablets, and smart TVs. The plan involves porting Unity from its current OpenGL-based implementation to Qt and implementing the Mir server. There are descriptions available on the Ubuntu wiki for both Mir and "Unity Next."

In a blog post, Ries elaborated further on the "overhaul" and the reasons behind it. It was already clear that the current implementation of the Unity shell (which runs as a plugin to Compiz) would eventually need to go; handling multiple monitors is problematic, as is implementing the global menu bar. The Ubuntu Touch devices are expected to add to the complexity by relying on different pointing devices and text input methods. In addition, Compiz itself was put into maintenance mode by its lead developer in December 2012.

In evaluating the options, Canonical decided that the X server needed replacing, and that Wayland was not viable for running on handheld devices. The new solution, Mir, is designed to run both on the system-on-chip (SoC) hardware found in phones and on standard desktop graphics hardware. The port of Unity from the OpenGL-based Nux toolkit is a reversal of sorts, Ries noted, but when Ubuntu halted work on its previous Qt-based implementation of Unity (the "fallback" mode for systems without sufficient graphics power to run Nux-based Unity) it did so in large part because Qt's future was uncertain. The project was in the midst of a hand-off from corporate owner Nokia to a community-governed council, and it was not clear that the Qt-based Unity would offer a comparable feature set to the OpenGL version. Now that Qt is in a stable and healthy position, Ubuntu has resumed work on the Qt-based Unity.

Thomas Voß wrote a blog post of his own, which lists several other rationales for Mir, including the ability to leverage existing Android drivers, and the desire for an input system suitable for mobile device usage. In addition, Weston, the reference implementation of Wayland, suffered from a "lack of a clearly defined driver model as well as the lack of a rigorous development process in terms of testing driven by a set of well-defined requirements." For a short-term solution, the project borrowed Android's SurfaceFlinger, but will replace it with Mir in time for the release of Ubuntu 14.04. Builds of both Mir and Unity Next will be available starting in a few months, although Ubuntu 13.04 and 13.10 are not expected to use them.

Specifics and protocols

The Mir wiki page goes into considerably more detail about the architecture of the system. It consists of a server-side library called libmir-server, a matching client communication library called libmir-client, and the unity-system-compositor. Other re-written Unity components include the Unity shell, Unity Greeter, and bindings for GUI toolkits (initially Qt, with GTK+ and SDL to follow). The Unity Next page further details how the changes will affect applications, such as the environment's launchers and notification system.

But the majority of the public discussion about the announcement has centered around the Mir display server—and in particular why it will not simply be an implementation of the Wayland protocol. For now, the Mir page lists a few reasons why Ubuntu decided Wayland did not fit the bill, including input event handling, input methods (that is, flexible mechanisms for text input, which are a more complicated issue for logographic writing systems like Chinese), and the manner in which shells and sessions are treated distinctly from normal client applications. On the other hand, the page does emphasize that Mir is designed to be "protocol-agnostic" and that Wayland support could be added in the future.

Not everyone found the reasons listed compelling, of course, particularly developers working on Wayland and Weston. Kristian Høgsberg started a discussion thread about it on Google Plus, in which several took issue with the Mir wiki page's description of Wayland's input event system. Most notably, the wiki page had initially said that Wayland's input events duplicated insecure semantics from X11's input system. Canonical's Christopher James Halse Rogers ("RAOF") later visited the Wayland IRC channel, and was asked about the security issue, which Høgsberg said was incorrect. Halse Rogers said he was unaware that the wiki mentioned the security issue, and subsequently removed it from the page.

The IRC discussion log makes for interesting reading, once one wades through the less compelling flame-like comments. Høgsberg also took issue with the Mir wiki page's comments about Wayland's distinction between normal client applications and special processes like the shell and session manager. The wiki page said that the shell-integration parts of the Wayland protocol were privileged, a design that the Ubuntu team disagreed with because it would require additional security measures. Høgsberg argued that the APIs provided were unprivileged, and that Ubuntu could replace any of them that it did not like without altering the core interfaces. In particular, the interfaces in question (wl_shell and wl_shell_surface) are actually optional extensions. In an interesting wrinkle, Wayland developer Tiago Vignatti posted a blog entry on March 5 describing the special protocol available to user shells, although he, too, said that it was not a privileged protocol.

In the IRC discussion, Halse Rogers countered that removing and replacing multiple interfaces would result in a display server that was not really Wayland anyway (and would require Ubuntu to maintain separate integration code for the GUI toolkits in particular). He added that Mir also uses a different (server-side) buffer allocation scheme in order to support ARM devices. Høgsberg replied that Wayland could add support for that as well, noting "I realize that this all isn't really documented, but it's not like Wayland only works with client side allocated buffers."

Divergent or convergent projects

Two other people in the IRC discussion raised a non-technical complaint, commenting that Ubuntu should have brought its issues with Wayland's design to the Wayland development mailing list, rather than develop a separate project. That does sound ideal, but on the other hand it is not easy to demonstrate that such a discussion would have guaranteed that Wayland evolved into the protocol that Ubuntu wanted. After all, at one point in the past, Ubuntu was planning on adopting Wayland; Mark Shuttleworth announced that intention in November 2010.

Canonical's Chase Douglas subsequently did join the Wayland mailing list, and on at least one occasion he weighed in on a design issue. The topic was touch input support in particular, in February 2012, and Douglas did not seem pleased with Wayland's touch event handling, noting specifically that it would not work when the user was sending touch events to more than one application. Most mobile platforms do not support having multiple foreground applications, but the tablet builds of Ubuntu Touch do.

Touch event handling is an interesting case to consider. The Mir wiki page cites input event handling as one of the project's points of disagreement with Wayland. It goes into frustratingly little detail on the subject, but Ubuntu is clearly interested in multi-touch and gesture recognition support due to its push on tablets and handheld devices. It debuted a multi-touch and gesture input stack with the release of Ubuntu 10.04, which it still maintains. Wayland, meanwhile, has stayed focused primarily on the desktop. In August 2012, there was an effort to revive the dormant weston-tablet-shell, although based on the commit logs it has been receiving less attention subsequently.

Certainly multi-touch and gesture-recognition are critical for phone and tablet user interfaces. Perhaps if Ubuntu is dead-set on implementing a touch-and-gesture-aware input event system that it can ship within the year, then the argument could be made that Wayland is not ready. There are few alternatives to Ubuntu's gesture framework; GTK+ gained multi-touch support in 3.4, but GNOME has only recently started working on its own touch event implementation. One might also make the case that no distributions have moved to Wayland itself, either, and it is not clear when Mutter or other window managers will implement it in a form ready for end users. There are other potential incompatibilities, such as licensing—Wayland and Weston are MIT-licensed; Mir is GPLv3. So Ubuntu could merge in Weston code, but submitting Mir patches upstream would mean adopting the other project's non-copyleft license.

None of those arguments are likely to sway the opinions of any Wayland developers toward Mir, of course. The best hope for peace probably lies in getting the two projects together to discuss their differences. On that point, Halse Rogers offered a tantalizing possibility in the IRC discussion, noting on line 215 that someone (possibly Voß) is attempting to organize such a meeting. In the meantime, however, most end users will simply have to sit still and wait to see what happens next. Ubuntu has declared its intention to ship Mir and Unity Next with Ubuntu 14.04; at the moment there is not a large distribution with a public launch date for its Wayland implementation, so it will be interesting to see which arrives first.

But one thing the Mir announcement and subsequent debate has made crystal clear is that both projects have fallen far short on the documentation front. The Mir wiki page and its associated Launchpad blueprints are all that currently exists, and they are short on detail. Then again, the Mir page is only a few days old at this stage. Wayland has been in active development for years, and its documentation, too, is sparse, to put it mildly. Høgsberg admitted as much in the IRC discussion, but who knows how many points of disagreement about Mir and Wayland compatibility could have been avoided entirely with more thorough documentation of the core and extensions. Neither project does itself—much less users—any favors when the only way to learn implementation details is to track down the lead developer and ask specific questions over email or IRC.

Ubuntu says it will begin making builds of Mir and Unity Next available in May 2013. Where both projects head over the course of the following year remains to be seen—as is also true with Wayland. A year from now, perhaps the two teams will have found common ground. If not, a head-to-head comparison of the software will surely make for a more interesting debate than does this week's strictly hypothetical discussion.


(Log in to post comments)

Derived distros

Posted Mar 6, 2013 22:27 UTC (Wed) by abatters (✭ supporter ✭, #6932) [Link]

If Ubuntu will be based on Mir and Unity is an integral part of it, how will this affect Ubuntu-derived distros like Linux Mint that provide a classic interface?

Derived distros

Posted Mar 7, 2013 0:13 UTC (Thu) by rahvin (subscriber, #16953) [Link]

There is a Debian Mint and several others I'll get wrong if I try to list them. Mint can be created from many different distributions. My guess would be Mint will simply migrate to Debian or another base.

Derived distros

Posted Mar 7, 2013 3:40 UTC (Thu) by horen (guest, #2514) [Link]

The future is already here! Linux Mint Debian Edition (LMDE) is alive and well and available for download in two different flavors here.

Derived distros

Posted Mar 7, 2013 16:31 UTC (Thu) by tjc (guest, #137) [Link]

The Linux Mint developers have already forked Gnome Shell (and a few other things), so I wouldn't be too surprised if they did the same with Mir, although it would probably be a much more difficult job. Or maybe they will use Wayland instead. Or re-base on Debian, as you say. They have options.

Derived distros

Posted Mar 7, 2013 0:45 UTC (Thu) by rqosa (guest, #24136) [Link]

> how will this affect Ubuntu-derived distros like Linux Mint

And Kubuntu, Xubuntu, and Lubuntu, also…

Derived distros

Posted Mar 7, 2013 20:18 UTC (Thu) by intgr (subscriber, #39733) [Link]

I'm sure that the X.org server will still be available from Ubuntu repositories for many years, it's not like this announcement forces them to change things overnight.

Derived distros

Posted Mar 7, 2013 23:51 UTC (Thu) by drag (subscriber, #31333) [Link]

It's not like Mir is going to be any time soon either. It's more vaporware then anything else. It's going to take them at least a couple years to get it into usable state to were they can even start thinking about replacing Xfree display server.

Ubuntu unveils its next-generation shell and display server

Posted Mar 6, 2013 22:45 UTC (Wed) by arjan (subscriber, #36785) [Link]

I find it curious that one of the hottest issues in graphical composited environments does not show up in the discussion at all so far: Memory bandwidth.

With screens going much bigger (finally!), and mobile formfactors leading to design tradeoffs that actually reduce the available memory bandwidth.... we're reaching the point where the current compositing copy operation ends up taking a significant %age of the total available memory bandwidth, turning it into a power and performance issue.

oh well.
I'm also not counting X out as being a viable long term option; yes the code is old, but it's been fixing many of the issues over the years via the flexible extension mechanism.

Ubuntu unveils its next-generation shell and display server

Posted Mar 6, 2013 23:44 UTC (Wed) by airlied (subscriber, #9104) [Link]

because choice of display server post X won't change that?

wayland can deal with hw overlay compositing if it can be used, and Mir well Mir has more TODO than LoC.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 5:37 UTC (Thu) by daniels (subscriber, #16193) [Link]

Like Dave said, Wayland actively encourages the use of overlays; we place surfaces into overlays whenever possible, and I'm currently working on a platform where we use the client buffers directly as full scanout buffers (requiring special allocation) when we can.

Everyone in mobile knows about memory bandwidth, it's something we've all been working on for ages. If you've any specific suggestions for improving Wayland's interfaces in this regard, I'd love to hear them.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 9:58 UTC (Thu) by dgm (subscriber, #49227) [Link]

> I'm currently working on a platform where we use the client buffers directly as full scanout buffers

Is that platform Pekka Paalanen's port to to the Raspberry Pi?

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 9:59 UTC (Thu) by daniels (subscriber, #16193) [Link]

> Is that platform Pekka Paalanen's port to to the Raspberry Pi?

No.

Ubuntu unveils its next-generation shell and display server

Posted Mar 6, 2013 23:30 UTC (Wed) by neilbrown (subscriber, #359) [Link]

Thanks for a well balanced article!

I'm having trouble sorting out the issue of "privilege protocols" though.

It seems to me that a "normal application" should only need to allocate one or more windows, draw on those windows, suggest where those windows should be on the display, and receive input events destined for those windows.

Other operations like grabbing all events and synthesising new events and making a window full-screen-with-no-decoration are needed for a window-manager or session manager, but are not needed for a "normal application" and so should not be available (principle of least privilege).

So I can well imagine there might be two protocol and only designated clients would be able to use the second protocol.

What I don't understand is why Ubuntu would say that the privilege requirement is a problem (especially as one of their complaints about X is that an unprivileged app can muck around with the input event stream arbitrarily) and I cannot see why Wayland people would say that the second protocol isn't privileged, when you clearly don't want just-any-app to be able to have control of every-window-on-the-display.

So I guess people are using the word "privilege" in some way subtly different to the way I'm using it.

Can someone explain?

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 1:08 UTC (Thu) by dlang (subscriber, #313) [Link]

> Other operations like grabbing all events and synthesising new events and making a window full-screen-with-no-decoration are needed for a window-manager or session manager, but are not needed for a "normal application" and so should not be available (principle of least privilege).

If I'm playing a HD video on a HD display, I really don't want to loose pixels around the edge and force the entire video to be rescaled. I really want my media player app to be able to go full-screen with no decorations.

synthesizing new events is also a very useful thing to be able to do. I created the Kiosk configuration that we used at Scale for the signs. It was a pretty simple "point a browser at a page and let it run", but it required both "full screen with no decorations" and "synthesizing new events", the first to make the page look right on the screen, and the second to move the mouse pointer out of the center of the screen so that it didn't obstruct and distract from the page being displayed.

note that I haven't read the article yet, and so I can't comment on the rest of your privilege questions, but the simple "why would anything other than a window-manager or session manager need to do this" question is one I wanted to comment on.

David Lang

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 1:26 UTC (Thu) by neilbrown (subscriber, #359) [Link]

Your media player should certainly be able to *request* full screen. It is up to the policy of the session manager whether to allow that, and how to break out of that.

Your Kiosk essentially *is* a session manager. It says "That window should be full screen, and hide the mouse cursor". You don't want apps from $UNTRUSTED_SOURCE to be able to do that, but you as system owner should certainly be able to do that.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 1:37 UTC (Thu) by dlang (subscriber, #313) [Link]

I agree, but if you require that only 'special' apps be written to use a particular api, then I as the admin loose any ability to use an app that way (without having to recompile it to use the new API)

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 17:09 UTC (Thu) by amaranth (subscriber, #57456) [Link]

You can't go fullscreen without the window manager's permission right now anyway, how is this any different? Sure, your window manager never says no but it certainly could (and even force your window size back down if you tried to make it "fullscreen" anyway).

Ubuntu unveils its next-generation shell and display server

Posted Mar 19, 2013 14:44 UTC (Tue) by Duncan (guest, #6647) [Link]

While I've not tried the fullscreen thing specifically, kwin's window rules do allow kwin to force many things, including window size and position, border toggle state, etc.

Actually, come to think of it I KNOW the fullscreen thing can be forced, as kde 4.10 now includes a kwin scripting ability, with one of the two shipped scripts being a "video wall" script that forces selected media app windows to fullscreen to all monitors instead of just one, when they go to fullscreen mode. So it could certainly deny fullscreening at all, as well.

(Of course kde being kde, the activation of this script is a configuration option. FWIW, I turned off the other script, but like this one enough to have patched it to apply to smplayer2, it applied to smplayer, vlc, and one or two others, originally, but not to smplayer2 without the patch, which here on gentoo I apply by simply dropping it in the appropriate /etc/portage/patches/ subdir so it's applied each time I update the app. I should submit it upstream, but I already submitted patches for superkaramba that have just sat on the open bug, no comment or any indication at all that anyone's even read them since I submitted them for 4.5 or whatever, thus years ago. That tends to be a bit of a disincentive to even bother filing any further kde patch-bugs. =:^( )

So sometimes the window manager /does/ at least redefines "fullscreen" to suit its own purposes. =:^)

Ubuntu unveils its next-generation shell and display server

Posted Mar 19, 2013 16:11 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

Keep in mind that KDE is not a group of a few hundred interchangeable resources that at all times work on all the projects. People work on their own area -- I never, no matter how much the temptation, have worked on kmail, for instance. The superkaramba project likely lost all activity when Plasma started supporting widgets. I don't know who the developers were, or where they went, but that superkaramba bugs don't get attention doesn't mean kwin bugs don't get attention.

The kwin team is really pretty active, and pretty responsive.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 10:25 UTC (Thu) by renox (subscriber, #23785) [Link]

I totally agree with you that normal applications should be able to go full screen, but I don't understand your use case for input event generation (that is the core of the security issue).
You wrote: "to move the mouse pointer out of the center of the screen so that it didn't obstruct and distract from the page being displayed."
so when you clicked on your media player it moved the mouse pointer?? Why didn't you just hide the mouse pointer if it stays idle a few seconds?
That's what most media player do and this doesn't require input event generation..

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 11:12 UTC (Thu) by hummassa (subscriber, #307) [Link]

> I totally agree with you that normal applications should be able to go full screen,

I don't. At least not without some kind of overlay (*). The minute a normal application can go fullscreen it can spoof security measures (for instance, ask the user for his password and store/send it somewhere).

(*) One possible solution here is an OSD overlay that can be shown for a limited time, like two to five seconds, after any input -- keystroke, mouse move &c and, after that, vanish (like youtube's and xbmc's fullscreen mode video controls). This way the user can watch a video or even read a book or a webpage using the whole screen estate but can't be deceived in thinking its login page &c is being displayed.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 11:33 UTC (Thu) by renox (subscriber, #23785) [Link]

>> I totally agree with you that normal applications should be able to go full screen,
> I don't. At least not without some kind of overlay.

It depends on the situation.. On your home PC, is-it really an issue?
To fool you into entering your password, the trojan must be able to replicate somehow your environment, which is quite difficult if it isn't allowed to generate input events (like Wayland does).
Where security is important, I think that it should be possible by administrators to disable full screen windows.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 19:39 UTC (Thu) by dlang (subscriber, #313) [Link]

> You wrote: "to move the mouse pointer out of the center of the screen so that it didn't obstruct and distract from the page being displayed."
so when you clicked on your media player it moved the mouse pointer??

There was no mouse or keyboard attached to the machine. There was no media player software running, just firefox viewing a HTML/javascript page.

I used a command-line tool (xwit) to inject a mouse movement action into the input event queue

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 2:23 UTC (Thu) by hoegsberg (guest, #57768) [Link]

We have a "wl_shell" interface in the wayland protocol, which provides the means by which applications set window titles, icons, go fullscreen, pop up menus. This interface is not privileged, it's available to all clients.

We have another interface called "desktop_shell". This is a weston specific, private interface, only available to a special helper client that weston launches. This client provides the background and panel surface back to weston through this interface. Similarly, our input method helper is launched by weston and injects input events back into weston using a privileged interface only available to that client.

The way we've split weston into different processes is not a requirement of wayland. The wayland protocol and core libraries doesn't dictate that a compositor should split all UI into external processes. Weston works that way because we don't have a toolkit inside weston. On the other hand, GNOME Shell, for example, uses clutter inside the compositor and can do much UI in the compositor process as a wayland compositor.

The Unity/Mir developers want to build the Unity UI into the compositor (as explained in the UDS Mir video), similar to how GNOME Shell would work. Their concern about the privileged shell interface and external helper clients seems to be that they think it's the only way to structure a wayland compositor.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 2:44 UTC (Thu) by neilbrown (subscriber, #359) [Link]

Thanks. That's very helpful.

If I might summarize:
- All *wayland* APIs are non-privileged. However they do not allow you to implement (e.g.) a panel or screen saver.
- Weston has a private and privileged API which can be used to implement a panel etc.

The (current) MirSpec says two things about "privilege".
Firstly "We want to avoid exposing any sort of privileged protocol to client applications." Neither Wayland or Weston do this anyway. Weston only exposes a privileged API to processes that it executes directly.

Secondly "As another example, we consider the shell integration parts of the protocol as privileged and we'd rather avoid having any sort of shell behavior defined in the client facing protocol."
I'm not really sure what this means. It could be taken to say "Stuff like wl_shell should be privileged", but that contradicts the earlier point, so is unlikely to be the intention. So it probably means "desktop_shell" shouldn't be part of the client-facing protocol, and that is exactly the case - it isn't.
So I agree that they seem to be confused. I wonder if anyone from Mir is reading and cares to comment.

"wl_shell" is and should be unprivileged.
"desktop_shell" is an implementation detail of weston, and is not client-facing so questions of privilege are irrelevant.

Thanks.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 0:31 UTC (Thu) by airlied (subscriber, #9104) [Link]

This article does make it sound like an arduous task of tracking down the maintainer on irc and asking him questions. seriously?

The thing is yes wayland could be documented better, would it have helped the Canonical developers avoid creating a replacement?

Tracking down someone like krh on irc isn't exactly burdensome, sending a mail to a mailing list saying we think wayland works like this, are we correct? could it work like this? this is open source 101.

If the only interface to wayland was a bunch of developer docs like MSDN then yes not talking to wayland would actually be more valid!

(also Chase no longer works for Canonical, hence why he stopped following up).

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 3:32 UTC (Thu) by n8willis (subscriber, #43041) [Link]

Well, I don't think I was saying it was arduous; but rather observing that incidents of miscommunication often have multiple causes (which definitely includes docs; which as a public entry point, can do many things - mitigate, or exacerbate, or entangle them). The level of detail provided on all sides appears to be a contributing factor; it did certainly appear that both sides came away from the IRC discussion with a better position on where the differences were; I'd certainly hope that that continues if (or when) there is subsequent discussion.

Nate

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 13:47 UTC (Thu) by dbnichol (subscriber, #39622) [Link]

I thought the same thing. The only way you get involved in a project, figure out the direction, and eventually try to guide the direction is to show up. I can't think of any open source project where you could have no contact with anyone on the project and feel you had a strong understanding of the its direction.

It seems like if the alternative is writing your own graphics stack from scratch, then you probably want to make sure you've got a full understanding of the project you're discarding.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 2:52 UTC (Thu) by dlang (subscriber, #313) [Link]

> Høgsberg replied that Wayland could add support for that as well, noting "I realize that this all isn't really documented, but it's not like Wayland only works with client side allocated buffers."

when a project makes a big point about how it uses client side buffers, and then doesn't document that this isn't the only way it works, it's not surprising that other people assume that it is.

I hope that someone is gathering all the undocumented things that wayland can do (and how to do them) that were incorrectly assumed to be impossible and is adding them to the wayland documentation.

for a project that is so loud on the need to break compatibility, it seems 'wrong' that they would take such offense at someone else breaking compatibility. It may be that one group or the other is headed into a dead-end, but to take the attitude that only they should be allowed to break compatibility is the height of arrogance.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 3:05 UTC (Thu) by airlied (subscriber, #9104) [Link]

insightful, -1.

Oh I forgot not the slashdot.

The thing is wayland isn't a hidden project, asking someone on irc or by email isn't hard. Making assumptions shows less character than challenging them. Try and find anywhere in the X11 documentation that explains how to write a window manager or compositing manager. That never stopped anyone from trying, much to our disdain in a lot of cases.

I don't think krh has ever said Mir shouldn't be allowed to exist, he has clearly stated that Mir shouldn't be bashing wayland in order to justify its existence, and that there may be no technical reason for Mir to exist apart from ignorance of wayland. Non-technical reasons for Mir's existence maybe also exist, that we are unaware of.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 4:19 UTC (Thu) by rsidd (subscriber, #2582) [Link]

The thing is wayland isn't a hidden project,
The thing is that wasn't the OP's point at all.

The thing is that wayland isn't an established project. It may not be hidden but, after five years, there is not a single product or distro that uses it or even has a timeline for when they will use it (correct me if I am wrong). Ubuntu wants to put something out in the next few months, and unify all their target devices by next year. Both projects are a break with X. Wayland should do a better job of explaining why they are the best way to do it, or else just let Mir be.

Yes, Mir made some incorrect claims about Wayland but those were corrected in less than a day. Are there any remaining examples of "bashing Wayland"? As a disinterested person (I use Ubuntu but not Unity), I don't think the Mir wiki "bashes" Wayland in any way.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 5:32 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> It may not be hidden but, after five years, there is not a single product or distro that uses it or even has a timeline for when they will use it (correct me if I am wrong). Ubuntu wants to put something out in the next few months, and unify all their target devices by next year.

This is probably the biggest issue that has created Mir. There have been a few links to a post by Shuttleworth from two years ago which discusses a presumed shift to Wayland that indicated Canonical wanted to integrate it in the next 6mo cycle. That obviously didn't happen and Wayland didn't seem to stabilize on the schedule needed for Ubuntu integration. Maybe there just isn't enough resources behind Wayland, did Canonical have developers working on it or did they expect that others would do all the work without their resources? It seems that they would have been hot to integrate it if it was ready a year ago, which would have probably prevented this whole issue.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 6:59 UTC (Thu) by airlied (subscriber, #9104) [Link]

Canonical have never provided any resources to the wayland project. They have waited for some other distro to do the heavy lifting, you have to also remember the wayland devs have not just been working on wayland for the past 5 years.

Most of krh's time has been spent getting the mesa gbm/egl layers to a place where wayland is actually possible, and open source stack supports it.

If someone had come along a year ago with a direction for wayland and 4-5 developers there would have been very little to stop them taking the project in whatever direction they wished. You'd at least talk to the upstream project first, to see what benefit you could gain from it.

There's a pretty good chance Fedora 20/21 will see some movement in waylands direction. But if Canonical had put the effort into wayland instead of Mir we might have had a reason to help out earlier and assign resources.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 14:02 UTC (Thu) by dbnichol (subscriber, #39622) [Link]

Writing a display server from scratch somehow accelerates their product? That doesn't make any sense at all. Not to mention that they're now doing this completely on their own now and will receive no help from the open source graphics veterans working on Wayland now like Kristian and Daniel Stone. People that have been doing this for years and have a pretty good idea of what a display server (X) should and shouldn't be doing.

If time to market was all they cared about, why not use X? Or why not just fork Wayland/Weston since that code already exists? Or just use SurfaceFlinger? I don't think time to market makes sense as the driver for Mir. It seems a lot more about control.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 17:05 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> Writing a display server from scratch somehow accelerates their product?

Not having to integrate or coordinate with anyone else accelerates development, just as Fred Brooks 8-)

> People that have been doing this for years and have a pretty good idea of what a display server (X) should and shouldn't be doing.

They might be able to get something lightweight that works 90% for their one use case without worrying too much about the corner cases, it's the last 10% to make it robust and complete where the difficult work is. This reminds me of mjg59's criticism of LightDM, by the time you've solved the real-world problems and discovered all the underlying requirements your "lightweight" system has just as much complexity as the "crufty" thing it was meant to replace.

So I think they can ship something that pretty much works, but it'll take years to get to the same place that Wayland is today, just like Wayland took years to build, and then they'll have another big of private infrastructure to maintain that takes away time from actually adding value to what they are selling.

Ubuntu unveils its next-generation shell and display server

Posted Mar 8, 2013 13:56 UTC (Fri) by robclark (subscriber, #74945) [Link]

> Not having to integrate or coordinate with anyone else accelerates development, just as Fred Brooks 8-)

well, maybe for whipping together a prototype.. for getting something that handles all cases (multi-display, hotplug, various different apps, etc) it is not. In the end we just end up with something that works ok in simple cases but is not as mature/robust as wayland, and everyone loses.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 11:59 UTC (Thu) by ewan (subscriber, #5533) [Link]

"Yes, Mir made some incorrect claims about Wayland but those were corrected in less than a day."

You say that as if it's somehow a good thing - the problem is that Mir exists (ostensibly) because of technical misunderstandings that could have been cleared up in less than a day months ago. Canonical devs just didn't even bother to try - that's the problem.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 4:30 UTC (Thu) by hoegsberg (guest, #57768) [Link]

I think perhaps you're confusing client side decorations for client side allocated buffers? Client side decorations come up again and again, but we've never really talked much about client side buffer allocation.

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.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 10:10 UTC (Thu) by dgm (subscriber, #49227) [Link]

>for a project that is so loud on the need to break compatibility

Wayland is not X11, and so it needs not be compatible in any way. Yet, X11 applications run just fine under Wayland (by means of XWayland).

How can you possibly call this behavior "being loud about breaking compatibility"? In any case, it's just the opposite!

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 11:03 UTC (Thu) by hummassa (subscriber, #307) [Link]

Honest questions:

* is XWayland already working?

* is Qt/Wayland working?

* is Kdelibs/Qt/Wayland working?

To the other side:

* is Qt/Mir already working?

* is Kdelibs/Qt/Mir working?

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 11:47 UTC (Thu) by ebassi (subscriber, #54855) [Link]

> * is XWayland already working?

yes

> * is Qt/Wayland working?

yes

I'll also throw in GTK and Clutter to the list of toolkits working under Wayland.

there are bugs? sure. are they being fixed? yes.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 19:23 UTC (Thu) by Serge (guest, #84957) [Link]

> Honest questions:

Don't ask people that like wayland — they will say you that it works. Don't ask people that hate wayland — they will tell you that it's not. Download livecd and try it yourself: http://sourceforge.net/projects/rebeccablackos/

Value for money or strategic underinvestment?

Posted Mar 7, 2013 13:04 UTC (Thu) by pboddie (subscriber, #50784) [Link]

Now that Qt is in a stable and healthy position, Ubuntu has resumed work on the Qt-based Unity.

It seems to me that Canonical could have invested in Qt instead of waiting to see whether some other organisation would pick up the tab.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 14:05 UTC (Thu) by el_presidente (guest, #87621) [Link]

So, to summarize the comments, nobody knows what Wayland is or what it does but it does it wrong.

If its developers don't like the comments on LWN, wait until they see the rest of the Internet.

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 17:13 UTC (Thu) by njd27 (subscriber, #5770) [Link]

Surely the question that should be asked is: when is the Mir project planning to implement remote rendering?

Ubuntu unveils its next-generation shell and display server

Posted Mar 7, 2013 22:10 UTC (Thu) by ovitters (subscriber, #27950) [Link]

That is a terrible summary.


Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds