1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Upstream X/Wayland Developers Bash Canonical, Mir

Fedora

Published on 04 March 2013 07:19 PM EST
Written by Michael Larabel in Fedora
116 Comments

Canonical's decision to develop Mir, their own display server not derived from X11 or Wayland, hit many as a big surprise today. Canonical previously committed to Wayland in a future Ubuntu release but now it turns out that for months they have secretly been rolling their own solution behind closed doors.

It will be interesting to see how the Mir situation plays out on Ubuntu, but already Canonical has once again disgruntled upstream open-source developers. Aside from end-users being surprised by this decision to no longer pursue Wayland, the X.Org and Wayland developers themselves were taken for a ride.

Kristian Høgsberg, the creator of Wayland/Weston, has posted to his Google+ page about the Canonical Mir announcement.

Long-time X.Org contributor Daniel Stone, who's also been commenting in our forum thread, was quick to say, "The best part is that the input bit of the rationale is totally wrong: there's no way for clients to get another client's input, short of mapping a full-screen transparent window and convincing the compositor to not decorate it. There also aren't any grabs. Which I could've told them if anyone involved ever bothered to talk to anyone upstream."

Stone later added, "I'm not worried about Wayland's future at all. I'm just irritated that this means more work for us, more work for upstream developers, more work for toolkits, more work for hardware vendors, and years of explaining that most of the page explaining that Mir had to be created because Wayland was a) hugely deficient, and b) unfixable, was total bullshit."

Kristian also followed-up to Stone's comments. Canonical's Mir specification about Wayland/Weston and its input shortcomings are inaccurate and their sought after input features are already implemented and working in Weston today.

Lennart Poettering, the Red Hat developer of systemd and PulseAudio fame, was quick to say, "I am sure 'Mir' is going to be a project with a fantastic future, just like bazaar, or Upstart, or Project Harmony before it." Lennart followed-up to himself with, "isn't Mir this thing that burnt and crashed into the South Pacific Ocean near Fiji on 23rd March, 2001, after some dudes in Russia flipped a switch after they gave it up? This must be metaphor for something, haven't figured out for what yet, though, must be something deeper than 'This software includes a space toilet and Canonical will give it up one day, when it will burn and crash and then we'll be in a south pacific paradise setting.'"

David Airlie, long-time X.Org/Mesa contributor at Red Hat, added, "They should call the next Ubuntu Jumping Sharks." Airlie followed up with, "they barely have anyone competent enough to write a display server, the fact that they are actually quite ignorant of how wayland works makes it even more apparent."

Carsten Haitzler, a.k.a. "Rasterman" of the Enlightenment project, wrote a lengthy post:
A reads of the mir stuff says to me "oh look. we don't understand wayland at all, neither do we grok X11 that much either".

Their reasoning on the input in wayland are just total bunk. It doesn't suffer from the X11 snooping/security issues. It's rather clean and neat and the compositor (be it weston or any other one) can decide where input is routed and when, and i'ts easy to do.

Their reasoning with respect to the Shell just smells of hand-wavy bunk to me. There is nothing privileged about it. It is part of the wayland protocol spec that a compositor may implement any way it likes as long as the results "work" given the shell style it is implementing. You need a shell because things like focus policies, other display policies etc. are implemented outside of clients and there has to be enough control and data sharing to enable that to work.

I would just say "ignore mir/canonical and just keep plodding on with wayland".
For those wondering, the C++ code-base that makes up Mir does require Canonical's CLA (Contributor License Agreement). Canonical also hasn't approached the upstream X.Org/Wayland developers officially. Using the open-source Mesa/Gallium3D driver does require a new EGL DRI2 driver that they currently have packaged in a Mesa PPA on Launchpad, but haven't yet attempted to upstream (or announce) its existence to Mesa developers.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. MSI X99S SLI PLUS On Linux
  2. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  3. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  4. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
Latest Linux Articles
  1. RunAbove: A POWER8 Compute Cloud With Offerings Up To 176 Threads
  2. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  3. Ubuntu 14.10 XMir System Compositor Benchmarks
  4. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
Latest Linux News
  1. openSUSE Factory & Tumbleweed Are Merging
  2. More Fedora Delays: Fedora 21 Beta Slips
  3. Mono Brings C# To The Unreal Engine 4
  4. Coreboot Now Has Support For Intel Broadwell Hardware
  5. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  6. GTK+ Lands Experimental Backend For Mir Display Server
  7. Ubuntu 14.10 Officially Released
  8. Mesa 10.4 Might Re-Enable HyperZ For R600g/RadeonSI
  9. Intel GVT-g GPU Virtualization Moves Closer
  10. GTK+ 3.16 To Bring Several New Features
Latest Forum Discussions
  1. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Linux hacker compares Solaris kernel code:
  4. HOPE: The Ease Of Python With The Speed Of C++
  5. Advertisements On Phoronix
  6. Users/Developers Threatening Fork Of Debian GNU/Linux
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed