LWN: Comments on "Riddell: Kubuntu Won't be Switching to Mir or XMir"

Riddell: Kubuntu Won't be Switching to Mir or XMir

micka — Wed, 03 Jul 2013 12:16:01 +0000

Community sure doesn't mean army of clones.
You don't need to have the same goal to form a community. You are even allowed to have disagreements...

Caring less

renox — Wed, 03 Jul 2013 08:25:30 +0000

You change a configuration file for Mir?

Caring less

mjg59 — Tue, 02 Jul 2013 19:44:44 +0000

I'm running an X environment on XMir. I want to move the screen on my HDMI output from the left of my internal display to the right of my internal display. How does that happen?

Caring less

dlang — Tue, 02 Jul 2013 19:26:55 +0000

it doesn't need to be in XMir, it just needs to be in Mir.

since XMir 'just' puts windows on the Mir desktop, any modesetting that Mir does benefits the entire desktop, including any XMir windows.

Caring less

mjg59 — Tue, 02 Jul 2013 16:03:23 +0000

Do you see any evidence of modesetting interface code in XMir?

Caring less

dlang — Tue, 02 Jul 2013 16:01:27 +0000

In my experience, Xorg does not run on all the embedded devices/tablets/etc that have Android drivers. In some cases it's been a matter of using the Android drivers or no display.

In addition, as others noted, even if Xorg is able to get some display on the device via the framebuffer driver, it can't always handle the modesetting and multiple outputs that the Android driver can.

Having a display beats not having a display.

Caring less

mjg59 — Tue, 02 Jul 2013 15:55:41 +0000

XMir will run on that device. Unaccelerated. X.org will also run on that device. Unaccelerated. How does that result in the user being better off?

Caring less

dlang — Tue, 02 Jul 2013 15:51:07 +0000

if Mir runs on a device, why would XMir not run on that same device (since it is just a layer on top of Mir)

since there are devices that have Android drivers but no X.org drivers, this means that XMir will run on some devices that X.org will not.

Other than the "it's not a free enough driver, so you should not use it" argument, how is someone not better off with XMir than Xorg in such a case?

Caring less

mjg59 — Tue, 02 Jul 2013 13:47:08 +0000

Yes, I was inaccurate. What I should have said is that XMir (as opposed to Mir) will not make use of unmodified Android drivers. As such there's no advantage in running XMir rather than Mir - dlang's original claim of "There is unfortunately a lot of hardware out there that has good Android drivers, but no good Xorg drivers. If you try to run on hat hardware, you will probably be better off with XMir than with Xorg" was wrong.

But you're right, the way I disagreed with it initially was (strictly) wrong and potentially misleading. I apologise for that.

Caring less

nye — Tue, 02 Jul 2013 11:23:31 +0000

You said:

>XMir doesn't run on top of unmodified Android drivers.

Then you said:

>It creates a Mir window and then renders into it

>how could Mir accelerate any of the operations?
>Bluntly, it would seem obvious that you don't know what you're talking about

You've just moved the goalposts and then attacked someone for not understanding where you've hidden them.

Caring less

raof — Tue, 02 Jul 2013 06:10:35 +0000

You do still get the advantage of whatever modesetting support the Android driver provides - the framebuffer interface isn't known for its sterling multi-head support.

Riddell: Kubuntu Won't be Switching to Mir or XMir

rodgerd — Tue, 02 Jul 2013 03:18:12 +0000

That's rich, unless you're going to be equally damning of Canonincal's long-running history of forking and declaring themselves the new upstream.

Caring less

mjg59 — Mon, 01 Jul 2013 22:06:27 +0000

X.org will run on any hardware that provides a framebuffer interface. You'll have zero acceleration, but in the absence of an X.org driver, XMir will also be unaccelerated.

Caring less

mjg59 — Mon, 01 Jul 2013 22:03:58 +0000

Look at the XMir source code. See any references to Mir protocol calls? It creates a Mir window and then renders into it. Mir has *zero* idea what's going on. In that situation, how could Mir accelerate any of the operations?

Bluntly, it would seem obvious that you don't know what you're talking about. Other windows are accelerated because the toolkits rendering into them are able to make mir calls. X clients can't.

Caring less

dlang — Mon, 01 Jul 2013 21:59:02 +0000

> Which provides no advantage over using X.org.

Well, if there are Android drivers for a device and there are not X.org drivers for a device, getting a display would seem like at least a minor advantage to me.

If the Mir stack can then take full advantage of acceleration (as indicated by the various links) then there's no reason to expect that XMir would not be able to make use of it.

Caring less

dlang — Mon, 01 Jul 2013 21:40:19 +0000

I posted links to the official Ubuntu site and to one of the developers FAQ sites.

Both of them explicitly say that Mir is able to use unmodified Android drivers to provide fully accelerated graphics.

If you are claiming that Mir windows on a Mir system will be accelerated, but XMir cannot use those drivers at all, that would seem to the statement that requires proof. It would seem obvious that if some windows on the screen can use Android drivers, that all the other windows on the screen would be using the same drivers.

Caring less

mjg59 — Mon, 01 Jul 2013 21:32:56 +0000

Which provides no advantage over using X.org. XWayland loads modified X.org drivers to provide hardware acceleration, and my understanding is that XMir behaves in the same way. I've seen no evidence that XMir is able to use Android drivers in any meaningful way.

(The fairly obvious subtext here is that dlang should stop making authoritative statements about things he doesn't understand)

Caring less

dlang — Mon, 01 Jul 2013 21:20:44 +0000

being that I'm not an X developer, I would assume that it works very similar to how X works for anything else. It has both the unaccelerated capability and whatever acceleration the drivers provide, XMir chooses which version to use based on what's available, just like Xorg would with different cards, some of which provide acceleration while others don't.

In either case, you can have the situation where sometimes the back-end provides acceleration, in other cases it doesn't. the X server (be it Xorg or XMir) will receive the same requests from the application and will decide how to render it.

Caring less

raven667 — Mon, 01 Jul 2013 21:04:54 +0000

I don't know but I would guess EGL or its not hardware accelerated. I would guess that it's not much different than XWayland, XAqua, XWin, etc. any system where X.org isn't directly driving the video hardware is going to have these same constraints.

Riddell: Kubuntu Won't be Switching to Mir or XMir

rgmoore — Mon, 01 Jul 2013 18:16:45 +0000

I said "never" in the context of Mir issue, because that's the context of rgmoore's comment.

I guess I didn't express myself clearly, then, because I really did mean that Kubuntu depends on Ubuntu as upstream for most of its stuff and only deliberately differs on the issue of the supported desktop. In that one case, the disagreement between Canonical and KDE about Mir vs. X and (eventually) Wayland is forcing them to make a choice about something beyond just the desktop. They must either choose either Mir, which isn't supported by upstream KDE, or X (and eventually Wayland) which is Canonical is deprecating.

Riddell: Kubuntu Won't be Switching to Mir or XMir

clint — Mon, 01 Jul 2013 17:11:27 +0000

No, it isn't.

Caring less

mjg59 — Mon, 01 Jul 2013 15:05:09 +0000

An X client connects to XMir. It sends an XDrawRectangle command. How does XMir turn that into a hardware-specific draw command?

Riddell: Kubuntu Won't be Switching to Mir or XMir

speedster1 — Mon, 01 Jul 2013 06:53:55 +0000

> Do you think it is OK for a display server to only work with Unity?
> DO you think it is OK for a DE/WM to only work with Xorg as X implementation?

I can tell you didn't follow my train of thought at all, so I'll try to explain better: carefully planned roadmaps can make roll-outs of significant changes a lot less painful to other people, so that you get a lot more cooperation in the long run.

Supposing you're in charge of the mir team with fairly limited manpower -- it's not a good idea to do a big switch-over with millions of users and suddenly break hundreds of applications at the same time, including plenty of apps with peeved maintainers who will go around telling everyone not to use mir because "it is a piece of junk" that "breaks everything".

Now suppose instead you just focused a second totally independent project to integrate with mir. This will bring out a lot more of the important bugs, especially since this second implementation is done with a lot less direct influence from the original in-house devs. After fixing the critical bugs turned up in this key effort, pick some more projects to persuade to try a mir port, and that will make it even more robust without turning the world against you.

Then mir is stable at the point you can reasonably include xmir as an alternative to xorg, but making sure that xorg is still available for users to easily switch in case they run into serious bugs that you can't quickly fix. Bugs in some obscure legacy apps may never get fixed, but who needs to waste time with those because the users will either continue to use a system frozen in time or else eventually find a replacement; on the other hand, properly maintained X apps should only have the occasional bug to deal with, and not a flood that makes them rebel and start closing all the xmir bugs. Plus having a quick way to switch to and from xorg allows users to work around bugs as they discover them, and less likely to get upset and rude on bug trackers (both for mir and for the affected apps).

Do you see anything wrong with the second, more conservative, approach? Is it likely to be bad for mir or unity in any way?

Caring less

dlang — Mon, 01 Jul 2013 06:51:40 +0000

since XMir is the X protocol on top of Mir, why would drivers that work with Mir not work with XMir?

Caring less

mjg59 — Mon, 01 Jul 2013 06:35:17 +0000

I didn't ask about Mir. I asked about XMir.

Caring less

dlang — Mon, 01 Jul 2013 06:31:57 +0000

lots of things, google for mir android drivers and you'll get back a bunch of links.

a couple of the more authoritative ones

http://unity.ubuntu.com/mir/android_technical_details.html

http://kdubois.net/?p=1815

quoting this second one:

> Does mir support android drivers?
>
> Yes! We put great care into our platform abstraction so that when you run on mesa desktop drivers, you use our mesa/gbm platform, but when you run mir inside of an Ubuntu Touch phone/tablet, you use the android platform to get full OpenGLES acceleration.

Caring less

mjg59 — Mon, 01 Jul 2013 06:26:41 +0000

What have you read that suggests it does?

Caring less

dlang — Mon, 01 Jul 2013 06:13:46 +0000

are you sure about that? everything I've been reading indicates that they do. What is it you are seeing that makes you think differently?

Caring less

mjg59 — Mon, 01 Jul 2013 04:33:13 +0000

XMir doesn't run on top of unmodified Android drivers.

Caring less

dlang — Mon, 01 Jul 2013 03:18:43 +0000

part of this also depends on what hardware you are talking about running on.

There is unfortunately a lot of hardware out there that has good Android drivers, but no good Xorg drivers. If you try to run on hat hardware, you will probably be better off with XMir than with Xorg, even with the extra layer.

Riddell: Kubuntu Won't be Switching to Mir or XMir

maxiaojun — Mon, 01 Jul 2013 02:08:29 +0000

Well, isn't X a protocol that allows multiple implementations and multiple implementations do exist?

If any DE/WM have trouble running on top of XMir, then either side might have bugs. And debugging can help either side.

Do you think it is OK for a display server to only work with Unity?
DO you think it is OK for a DE/WM to only work with Xorg as X implementation?

Caring less

maxiaojun — Mon, 01 Jul 2013 02:01:07 +0000

> Also, Kubuntu is still based on the Ubuntu repositories and much like Lubuntu and Xubuntu can be installed along side Ubuntu with a simple apt-get command.

Is it still that simple if vanilla Ubuntu uses XMir or Mir while derivatives don't?

Riddell: Kubuntu Won't be Switching to Mir or XMir

speedster1 — Sun, 30 Jun 2013 19:15:46 +0000

The switch from xorg to xmir is not going to be easy like Canonical management seems to be hoping; these things never are in the real world, where users have millions of different combinations of graphic cards and desktop settings and favorite applications.

If I were on the mir dev team, I would be wishing strongly that management switch to the more conservative roll-out that jspaleta recommends. I would want to be focusing on shaking out all the mir issues with Unity, and trying to recruit some other DE that wants to be adventurous to be the next guinea pig. A smaller one, that would have something to gain by the publicity of having a mir port, not KDE or Gnome.

Smart Ubuntu devs may already have this as their fallback plan: they can install xorg alongside xmir, and put in a user-friendly way to switch between backends. When compatibility issues crop up in RC testing, they can also switch the default backend to classic xorg for Lubuntu and Xubuntu installs (and Kubuntu could follow suit).

Caring less

gmatht — Sun, 30 Jun 2013 16:10:29 +0000

Canonical seems quite happy that Kubuntu is being continued to be supported and have "no issue" with their trademark being used. If Canonical wants to claim that Kubuntu is bringing disrepute to their trademark then fine, but I don't really care if whether you approve of Kubuntu's use of someone else's trademark. Also, Kubuntu is still based on the Ubuntu repositories and much like Lubuntu and Xubuntu can be installed along side Ubuntu with a simple apt-get command. This is more important to me than whether it uses Mir or not.

Riddell: Kubuntu Won't be Switching to Mir or XMir

maxiaojun — Sun, 30 Jun 2013 05:12:26 +0000

I don't expect Xfce and LXDE switch to Wayland any time soon either, probably never, unless one day they are forced to use XWayland or XMir. I guess you probably know Xfce better than me.

But anyway, LXDE/Lubuntu people is much less annoying than their KDE/Kubuntu counter part.

Riddell: Kubuntu Won't be Switching to Mir or XMir

maxiaojun — Sun, 30 Jun 2013 05:02:03 +0000

My bad, I didn't notice that you said "didn't" twice.

But again, he said "The future is unpredictable and we'll do what makes sense when we get there." to prove my "No, I've never seen Kubuntu devs showed any interest following Ubuntu as upstream. They just repeat Mir FUD all the times and never show people anything concrete." in the context of Mir issue wrong?

As for not good switching display server for an LTS, this is the reason why one should start from 13.10, if the team concerned has non-zero interest.

Riddell: Kubuntu Won't be Switching to Mir or XMir

mathstuf — Sun, 30 Jun 2013 03:32:28 +0000

Did you even read my comment or just pick keywords out to get your own meaning from it? How did what he said contradict that? He *did not say that 14.04 wasn't decided*, only that 13.10 has been. In any case, I can't fault them for going with not doing an initial release for a new, untested, display server in an LTS release.

Riddell: Kubuntu Won't be Switching to Mir or XMir

rahulsundaram — Sun, 30 Jun 2013 03:19:30 +0000

It isn't just Kubuntu. None of community spins seem ready to ship Mir without upstream support and unless there is a compelling advantage, I don't expect they will anytime soon.

http://lubuntublog.blogspot.com/2013/06/lubuntu-willl-not...

Riddell: Kubuntu Won't be Switching to Mir or XMir

maxiaojun — Sun, 30 Jun 2013 02:57:15 +0000

If Riddell is decided while another guy says he is undecided, I still count Kubuntu as decided.

Riddell: Kubuntu Won't be Switching to Mir or XMir

jspaleta — Sun, 30 Jun 2013 02:44:57 +0000

Xmir supporting everything else is still a problem for any non-Canonical backed upstream development team. Until an upstream affirms they are willing to deal with any xmir related regression issues and affirm they are interested in and have the capability to smoke test their DE on top of xmir as part of their upstream development..then Ubuntu as a project should hold off on having the DE operation ontop of xmir as default.

For 13.10 the compromise solution here is to default Unity8 to Mir and Unity7 to Xmir and everything else runs over xorg X11 by default with the option for users to switch over to xmir for any DE. This approach gives external upstream devs and DE users the piece of mind of being able to work with a known stack by default while at the same time giving them all the ability to approach xmir on their own terms and to hopefully gain some confidence in it being something they can support upstream without being forced to abruptly deal with it without a FULL ubuntu release cycle to come to terms with the tech.

Canonical is on a forced march with Unity and Mir over the precipice . And that's fine for them, their engineer and their management team. But they can't not expect to drag all the competing DEs developers along with them and its foolhardy and wasteful in terms of political capital to even attempt it (they've burned so much trust already with the announcement). The way forward is to make Mir and Xmir an optional tech preview for all the other DEs in the Ubuntu repository. Gives those projects a chance to come to terms with Mir/Xmir as delivered in 13.10 with the hope they'll affirm its a supportable stack for 14.04.