LXDE-Based Lubuntu Will Not Ship Mir Display Server

[bartek]

Should be noticed Wayland doesn't fit Lubuntu's needs either.

Why wouldn't it?

XMir is going to be the X stack that receives the most attention from Canonical, as well as from other Ubuntu developers working on Ubuntu-Unity.
The Lubuntu team won't have resources to maintain their own display stack ...
And given the tendency for bugs to arise as a result of mismatches between X+mesa, or X+mesa+kernel.

So I'm convinced that Lubuntu (and others) will switch to XMir / Mir by 14.04 (or 14.10)
If not then I'm skeptical that there is any long term future for non-Unity flavors in Ubuntu

[Luke]

If Ubuntu becomes Mir-Only, flavors could migrate to Debian

XMir is going to be the X stack that receives the most attention from Canonical, as well as from other Ubuntu developers working on Ubuntu-Unity.
The Lubuntu team won't have resources to maintain their own display stack ...
And given the tendency for bugs to arise as a result of mismatches between X+mesa, or X+mesa+kernel.

So I'm convinced that Lubuntu (and others) will switch to XMir / Mir by 14.04 (or 14.10)
If not then I'm skeptical that there is any long term future for non-Unity flavors in Ubuntu

If this happens projects using non-Unity DE's could migrate to Debian or any other distro that uses Wayland or X. If nothing else, Mint should be strong enough to mantain a graphics stack. People who do not run Unity on their own machines will have these options:

1: stop updating anything but kernels and applications
2: Migrate to Debian or a flavor/external derivative that migrated to Debian. Mint already has a Debian version for insurance, for example.
3: Replace the graphics stack with upstream X or Wayland and their favorite DE from a PPA

No way in hell I'm going to run Unity or any other phone/tablet interface on my keyboard and mouse driven workstations or laptop. About as useful as putting IceWM (from my netbook) on a touch-only tablet. For me, dumping a patched Ubuntu version of Mesa for an upstream version that supported Wayland or X would be no big deal, it should be even less of a problem for maintainers of something like Mint. I could even see Mint taking over non-Unity graphics mantainance, and the ability to install their packages from PPA's would allow any flavor willing to use that PPA or Mint's own repos to continue to exist. Ideally Ubuntu and Mint would collaborate, with Mint taking responsability for desktop interfaces and Ubuntu handling tablet and smartphone interfaces. That would be the team to take on Microsoft (and Crapple) head-on across the entire spectrum of devices.

[mrugiero]

No. The GPL could only be revoked if the code was obtained illegally and the organization never had the right to publish it under GPL in the first place.

Copyright transfer it not possible under EU laws. One can only transfer the right of use. This is why FSF Europe?s ?Fiduciary Licence Agreement? is different from FSF USA?s copyright assignment.
Canonical?s CLA works just like copyright assignment in practical terms: Canonical is exclusively in the position to choose any license for Mir with no legal binding to ever again provide FOSS versions (FSF and Qt Project have these provisions).

Can you read the post, please? I said: if you are the only copyright owner it *could be possible*, tho there are no successful precedents, to revoke the license.
Some people misread (and I used the exact same term in the quoted post) the CLA and believe you are transferring them the copyright, so they are lead to believe, incorrectly, that Canonical can revoke the GPL. There is precedent for an attempt to revoke the license, when having the copyright, but they made a deal outside of the court. Even in that case it's arguable that you can do that in a retroactive way, as already explained by that user.

I already said they can only make derivatives without releasing the source code with the same license.

So, you quote me to correct me rephrasing what I already said.

XMir is going to be the X stack that receives the most attention from Canonical, as well as from other Ubuntu developers working on Ubuntu-Unity.
The Lubuntu team won't have resources to maintain their own display stack ...
And given the tendency for bugs to arise as a result of mismatches between X+mesa, or X+mesa+kernel.

So I'm convinced that Lubuntu (and others) will switch to XMir / Mir by 14.04 (or 14.10)
If not then I'm skeptical that there is any long term future for non-Unity flavors in Ubuntu

It doesn't make it any more optimal. Fitting their needs and being the only option they have are not the same thing. If they want a supported stack, yes, they will eventually have to switch to XMir (pure Mir is still a non-option for what they aim to) or change the base distribution. But this lack of options doesn't mean XMir or Mir is a good solution for them, it's just the only supported one.

If nothing else, Mint should be strong enough to mantain a graphics stack.

I'm not really too informed about Mint, but isn't it kind of just a flavor with closed drivers by default or something like that? I don't think that requires any more resources than Kubuntu, for example. And they seem to be deeply screwed by the Mir situation.

[Luke]

Mint team strong enough to fork Gnome-shell for Cinnamon

I'm not really too informed about Mint, but isn't it kind of just a flavor with closed drivers by default or something like that? I don't think that requires any more resources than Kubuntu, for example. And they seem to be deeply screwed by the Mir situation.

Mint started out that way, but the GNOME 3 mess meant they had to put up or shut up. Since Mint tries to be easy for users migrating from Windoze XP/Vista/7 to use, they needed to keep their single taskbar on the bottom, traditional layout. At first, they wrote the MGSE (Mint Gnome Shell Extensions) to reconfigure gnome-shell to work like GNOME2, but upstream changes kept breaking that. Same issue gnome-shell frippery has to deal with. Disgusted, they forked gnome-shell, hardcoded in the traditional layout, added a slew of configuration utilities and named it Cinnamon. They forked Mutter to support it, calling it Muffin. Now they are forking every GNOME piece necessary to run the shell, so it will be possible to install it alongside an incompatable or no GNOME version, all the way down to GTK3.

Surely a team able to fork GTK3 will be able to handle patching Mesa or using an unpatched Mesa, then dropping it into their repo that "overlays" the Ubuntu repos in their distro. They can stay with X and their existing fork of the shell, or migrate to Wayland and fork the Wayland version of shell. My guess is they are going to be the strongest team working on reverting undesired changed from upstream. They also maintain GNOME 2 under the name of MATE, and both GNOME 2 and early GNOME 3 versions of Nautilus known as Caja and Nemo respectively.

Meanwhile the Xubuntu team is depended on by UbuntuStudio and possibly others. If they use Xmir, Ubuntustudio gets a serious problem, if they go to native Wayland they get good performance on newer hardware but leave pre-compositing machines by the side of the road. If they stay with X they too will need Mesa versions that support X. This work need be done only once.

Xubuntu, Lubuntu, Kubuntu, and Mint all could share resources in keeping a Mesa stack that works for all of them viable. Ideal would be to ensure that Ubuntu does their mesa patches in such a way as to create a driver that supports Mir, Wayland, and X all at the same time. GNOME will have a version supporting Wayland, so long as that version supports X, Ubuntu would need only to ensure that their Mir patches don't break anything else. Between Ubuntu and Mint there should be enough programming skill to get "3-way Mesa" done.

[bwat47]

EDIT: Anyway, if not using compositing, tearing is expectable because it redraws everything at every frame. XMir have an independent X server inside. If this X server doesn't have compositing enabled, you will have exactly the same problem. If it's enabled, you will not face those problem, but you won't if you enable compositing on X either (Openbox doesn't support compositing, so the closest you can get is using Fluxbox git, which has got compositing since 2012 or 2011).

In regards to the tearing. Xubuntu recently released a test ISO that has XFCE running on unity-system-compositor/xmir. In this configuration, with xfce's xrender compositor (which has tons of tearing running under plain X because xrender has no way of doing vsync), had absolutely no video tearing! scrolling in firefox was butter smooth with no tearing, fullscreen video no tearing, moving windows had no tearing. So I guess it is indeed possible that running a desktop that does not have opengl compositing to get tearing removed by running it via xmir...

I didn't try it with XFWM's compositor disabled, but I am 100% certain that it is not XFWM that was giving me the tear-free output, because as I mentioned before xfwm's compositor uses xrender which does nothing do address tearing, and tears like crazy on plain X.

EDIT: Just tested with xfwm's compositing totally disabled. STILL no tearing on xmir! For this reason I think xmir could actually be a big advantage to xubuntu and lubuntu, because right now they suffer from tearing issues unless you use a 3rd party opengl compositor. And just to make sure I looked at /var/log/Xorg.0.log to ensure that intel's "TearFree" was disabled, and it was, so it was unity-system-compositor/xmir providing the tear-free. I'm glad xubuntu is at least considering xmir, unlike lubuntu.

This is on intel HD4000 graphics.

On this machine I didn't notice any performance issues either (at least for basic desktop usage like web browser, watching video etc..) It actually seemed to run smoother than my current xubuntu 13.04 + compton setup too. Less input delay moving windows and even smoother smooth-scrolling in firefox.

I'm no mir fanboy either, but after actually testing xmir briefly I think it could actually be a good solution.

[mrugiero]

In regards to the tearing. Xubuntu recently released a test ISO that has XFCE running on unity-system-compositor/xmir. In this configuration, with xfce's xrender compositor (which has tons of tearing running under plain X because xrender has no way of doing vsync), had absolutely no video tearing! scrolling in firefox was butter smooth with no tearing, fullscreen video no tearing, moving windows had no tearing. So I guess it is indeed possible that running a desktop that does not have opengl compositing to get tearing removed by running it via xmir...

I've got that with X11. Since I didn't name OpenGL, you should assume I'm talking of compositing, plain and old, not specifically compositing depending on OpenGL.

I didn't try it with XFWM's compositor disabled, but I am 100% certain that it is not XFWM that was giving me the tear-free output, because as I mentioned before xfwm's compositor uses xrender which does nothing do address tearing, and tears like crazy on plain X.

First, no, you are not certain if you don't test it. That's what testing is for. Most programmers are certain there code is correct, but bugs exist, so...
On xrender doing nothing, well, in most cases, and specifically in the case I named, it does the only thing is lacking: several buffers for the images to be there, so displaying only means compositing them. That's enough in a lot of cases to avoid tearing, and that's enough in my case. With X.org.
As for XMir helping you, this might have something to do with Mir working as a compositor, since it might display the older screen until the new one is ready (sort of what double buffering does), so you see only correct screens, at a slightly lower framerate. I'm not sure how XMir/XWayland works on this regards, but I think it's possible to make it double-buffer the screen without the apps acknowledging it, probably with the help of the damage extension. Maybe this is not even needed if they emit timestamps at every change (it would be kind of the same, though). I didn't think about this possibility before. But it's a hack, anyway.

EDIT: Just tested with xfwm's compositing totally disabled. STILL no tearing on xmir! For this reason I think xmir could actually be a big advantage to xubuntu and lubuntu, because right now they suffer from tearing issues unless you use a 3rd party opengl compositor. And just to make sure I looked at /var/log/Xorg.0.log to ensure that intel's "TearFree" was disabled, and it was, so it was unity-system-compositor/xmir providing the tear-free. I'm glad xubuntu is at least considering xmir, unlike lubuntu.

Your experience is really different to mine. I have no tearing, and I use XFWM compositor. Also, the problem with text input is still standing. I'll look into launchpad this afternoon, I thought it was reported but it might be missing.

This is on intel HD4000 graphics.

Mine is on AMD A10, IIRC 4600 or something like that, using the APU.

On this machine I didn't notice any performance issues either (at least for basic desktop usage like web browser, watching video etc..) It actually seemed to run smoother than my current xubuntu 13.04 + compton setup too. Less input delay moving windows and even smoother smooth-scrolling in firefox.

Well, it might have something to do with the fact you are testing with the same drivers the main testing is being done. I'm using R600g, and it just recently became somewhat usable. Text input lags and reflects on the virtual terminal (which is a bug and a security issue), and flickers (the cursor goes back and forth). Aside from that, is relatively snappy, around as usable as X.org. Feeling smoother could be placebo, for all I know, until I see numbers or a reason for it to happen. It's completely subjective. I tried not to share subjective feelings when informing my testing, but checked things that, at least on the same computer, could be noticed by other people, like the cursor going back and forth, or the memory use reported by the system (which I said in another thread, is going down by now).
EDIT: If the idea is to share subjective feelings, I feel there is no reason for even Mir to exist. But I didn't want to keep the flamewar on, it exists, it will keep existing until (if) Canonical decides they were wrong, and nothing I say will change that. But my testing will, hopefully, help to avoid some of the problems I think my friends using Ubuntu (the flavor) might suffer, and that's why I do it.

I'm no mir fanboy either, but after actually testing xmir briefly I think it could actually be a good solution.

And I think it's no good because it doesn't solve anything for me, on my testing, and I see no reason to run a desktop this way. It's still a huge hack.

[bwat47]

I've got that with X11. Since I didn't name OpenGL, you should assume I'm talking of compositing, plain and old, not specifically compositing depending on OpenGL.


First, no, you are not certain if you don't test it. That's what testing is for. Most programmers are certain there code is correct, but bugs exist, so...
On xrender doing nothing, well, in most cases, and specifically in the case I named, it does the only thing is lacking: several buffers for the images to be there, so displaying only means compositing them. That's enough in a lot of cases to avoid tearing, and that's enough in my case. With X.org.
As for XMir helping you, this might have something to do with Mir working as a compositor, since it might display the older screen until the new one is ready (sort of what double buffering does), so you see only correct screens, at a slightly lower framerate. I'm not sure how XMir/XWayland works on this regards, but I think it's possible to make it double-buffer the screen without the apps acknowledging it, probably with the help of the damage extension. Maybe this is not even needed if they emit timestamps at every change (it would be kind of the same, though). I didn't think about this possibility before. But it's a hack, anyway.


Your experience is really different to mine. I have no tearing, and I use XFWM compositor. Also, the problem with text input is still standing. I'll look into launchpad this afternoon, I thought it was reported but it might be missing.


Mine is on AMD A10, IIRC 4600 or something like that, using the APU.


Well, it might have something to do with the fact you are testing with the same drivers the main testing is being done. I'm using R600g, and it just recently became somewhat usable. Text input lags and reflects on the virtual terminal (which is a bug and a security issue), and flickers (the cursor goes back and forth). Aside from that, is relatively snappy, around as usable as X.org. Feeling smoother could be placebo, for all I know, until I see numbers or a reason for it to happen. It's completely subjective. I tried not to share subjective feelings when informing my testing, but checked things that, at least on the same computer, could be noticed by other people, like the cursor going back and forth, or the memory use reported by the system (which I said in another thread, is going down by now).
EDIT: If the idea is to share subjective feelings, I feel there is no reason for even Mir to exist. But I didn't want to keep the flamewar on, it exists, it will keep existing until (if) Canonical decides they were wrong, and nothing I say will change that. But my testing will, hopefully, help to avoid some of the problems I think my friends using Ubuntu (the flavor) might suffer, and that's why I do it.


And I think it's no good because it doesn't solve anything for me, on my testing, and I see no reason to run a desktop this way. It's still a huge hack.

Tearing wih xrender compositing is an old and well-known issue. With intel's driver at least, on plain X without a page-flipping opengl compositor you WILL get video tearing. (and this isn't just some kind of intel "driver issue" modern intel hardware is actually designed with a page-flipping compositor in mind, it is designed this way so they could de-couple the rendering and display engines to allow the hardware to be in a power-saving state more often, reducing power usage).

And since you quoted my edit, surely you realized that I did indeed go in afterwards and test it with NO COMPOSITING and still got no tearing, which clearly shows the unity-system-compositor/xmir setup was indeed doing the tear-free, not xfwm's compositing. I also verified that intel's tearfree driver option was disabled. I tested this on both of my laptops too (one intel hd4000, one intel ironlake). Both of these laptop have extremely noticeable video tearing with XFCE's compositing on plain X, and both had no tearing with XFCE on xmir, with and without compositing.

Perhaps I should have been more clear though, I don't think its only xmir preventing the tearing, it probably does have more to do with the fact that xmir runs on top of the unity-system-compositor. I'd imagine the reason this setup is tear-free on intel hardware is because unity-system-compositor is probably making sure page-flipping is done.

And in regards to the smoothness. I'm not saying its necessarily faster than XFCE with regular X + an opengl compositor, but at the very least for desktop use it performed with "parity" and wasn't any slower. Tasks like smooth-scrolling in firefox, moving windows etc... were very smooth. And on my setup I did not notice any isues with text input in firefox or in xfce-terminal, so perhaps it is some kind of bug effecting your driver?

I think my point still stands, Running a desktop on top of USC/Xmir can vastly improve the video tearing situation (at least on the intel driver, possibly other drivers but I don't have non-intel hardware to test), and performance seemed totally fine (again, at least on the intel hardware I have available to test) And intel is very common hardware, that is a popular choice for linux users because it is well supported, so even if it only improves the tearing situation on intel, thats still a big win.

Video tearing on linux has always been a very large pet peeve of mine, and I am a big proponent of wayland's "every frame is perfect" idealogy. So anything that improves the video-tearing situation is a good thing in my book. You can probably see from my earlier posts that I am not a mir fanboy, and in fact a wayland supporter, and I agree that it would have been better had canonical worked with upstream on wayland, but I do not "hate" mir. Canonical is probably never going to just "drop" mir and decide to go for wayland, so I hope that both projects are successful. Flamewars and wishing the death of one or the other doesn't really help anything.

[mrugiero]

Tearing wih xrender compositing is an old and well-known issue. With intel's driver at least, on plain X without a page-flipping opengl compositor you WILL get video tearing.

Well, I don't suffer from it with xrender compositing, and I at times can notice it without xrender. You don't need page-flipping all the time. It is the final solution for this kind of problem, but for a subset (that covers all or almost all of my usage) compositing is all you need. Of course, it still depends on your setup (a faster card is less likely to show tearing, while a bigger resolution is more likely).

And since you quoted my edit, surely you realized that I did indeed go in and test it with NO COMPOSITING and still got no tearing, which clearly shows the unity-system-compositor/xmir setup was indeed doing the tear-free, not xfwm's compositing.

And since you quoted my post, you surely realized I said this is probably because Mir is doing pageflips of the output of XMir.
On pointing out not testing is not certainty, it still stands. The fact you later tested it doesn't change the fact you'd state "certainties" without actually testing, first.

[bwat47]

Well, I don't suffer from it with xrender compositing, and I at times can notice it without xrender. You don't need page-flipping all the time. It is the final solution for this kind of problem, but for a subset (that covers all or almost all of my usage) compositing is all you need. Of course, it still depends on your setup (a faster card is less likely to show tearing, while a bigger resolution is more likely).



And since you quoted my post, you surely realized I said this is probably because Mir is doing pageflips of the output of XMir.
On pointing out not testing is not certainty, it still stands. The fact you later tested it doesn't change the fact you'd state "certainties" without actually testing, first.

I am quite certain that XFWM wasn't providing me with tear-free compositing. It is impossible for xrender to be tear-free at all on modern intel hardware, because of how the hardware is designed. On modern intel hardware you **need** a page-flipping compositor to get any kind tear-free output. There is no way that xfwm's compositing was providing me with tear-free output, and I knew it was most likely USC/xmir. AMD's hardware does not work the same as intel's hardware. On intel you do **need* page-flipping for any kind of tear-free.

Here is a quote from an intel developer:

First note that all Intel hardware up to SandyBridge has functional vsync support with no greater cost than stalling the GPU until the blit can proceed.

The problem is that with the agressive powersaving of SandyBridge and the greater decoupling between the display engine and the GPU, the ability to delay rendering until a particular scanline had passed was assumed to be a legacy feature and the GPU commands to do so were removed. By presuming that all updates would then be through a compositor using pageflipping (i.e. their primary target, Windows Vista/7/8), they were then able to make further power savings. If you use an OpenGL (really DRI2) compositor that only pageflips (i.e. doesn't try to take "advantage" of MESA_copy_sub_buffer), you will not see any tearing, suffer very little jitter, and maximise the power savings of the GPU.

I will digress that I should have tested it to make sure *before* making the statement though. I was just excited and had already started writing the post before realizing I forgot to test without compositing, and immediately after writing the post I rebooted to test without compositing to confirm.

And since you quoted my post, you surely realized I said this is probably because Mir is doing pageflips of the output of XMir.

I actually agree with you here, and I edited my previous post stating exactly this before I refreshed the page and read this one In my original post I specifically made sure to mention "unity system compostor/xmir" to indicate that I don't think its xmir itself removing the tearing, but the whole xmir on top of USC stack, but I should have been more clear. (and since afaik xmir has to run on top of USC anyway, we are just arguing semantics, just know that when I say "xmir is preventing tearing, I do in fact mean the Mir +USC + xmir stack ).


So IMO my statement that running a desktop that does not support opengl compositing (such as lxde and xfce) on top of xmir can be quite advantageous holds true, because it solves the large issue of tearing on intel hardware. (and intel hardware is very common for linux users, so its not like it only solves tearing on some obscure hardware).

[mrugiero]

I am quite certain that XFWM wasn't providing me with tear-free compositing. It is impossible for xrender to be tear-free at all on modern intel hardware, because of how the hardware is designed. On modern intel hardware you **need** a page-flipping compositor to get any kind tear-free output. There is no way that xfwm's compositing was providing me with tear-free output, and I knew it was most likely USC/xmir. AMD's hardware does not work the same as intel's hardware. On intel you do **need* page-flipping for any kind of tear-free.

Indeed. As I pointed out on my first post, this makes sense, but I didn't think previously about that. I still consider this kind of solution a hack, since you add a whole layer of rather complex software to solve it. Both Wayland and Mir are probably more real solutions to this kind of problem, the same way using OpenGL pageflips on a more native way is a real solution.

I actually agree with you here, and I edited my previous post stating exactly this before I refreshed the page and read this one In my original post I specifically made sure to mention "unity system compostor/xmir" to indicate that I don't think its xmir itself removing the tearing, but the whole xmir on top of USC stack, but I should have been more clear. (and since afaik xmir has to run on top of USC anyway, we are just arguing semantics, just know that when I say "xmir is preventing tearing, I do in fact mean the Mir +USC + xmir stack ).

I actually read it as you intended. But I thought an explanation of why this was relevant was needed, so I did give the reason I though it was working that way


On the text input, have you tried with a text editor? I don't remember having problems with Firefox, but I didn't do extensive testing on that side (just the basic usage to log on the memory use, the last time, and I save it in a text file).

On Lubuntu not considering XMir, I think it totally makes sense (disregard the fact I generally feel XMir is not a good solution for a desktop), since they don't want to use compositing at all, of any kind. Their reason is completely consistent with their aim, which is minimal memory use (I said it a thousand times, but to avoid any confusion I'll say it again: I'm not saying Mir will increase memory use itself, but the buffers required for compositing).