Canonical Shows Legacy X11 Apps Running On Mir With Unity 8

[Meteorhead]

I have, and I think you're exaggerating the difference a lot.

This is simple a OpenGL tutorial using X11/GLX directly: https://www.opengl.org/wiki/Programm...:_GLX_and_Xlib
And this is a simple OpenGL tutorial using WinAPI/WGL: https://www.opengl.org/wiki/Creating...L_Context_(WGL)

Keep in mind the X11 code is rendering polygons while the WinAPI code is just creating a context.. but even still the difference is minimal. X11 is not some hellish API (not that's it's perfect by any means) and Wayland will surely improve things a lot.. You should be using something like SDL or GLFW for context creation and event handling anyways, and those are far from complicated.

The exmple you linked takes many things implicitly, for example the GLX versioning.

You are right, that for context creation SDL and the likes are very nice (I vote for SFML), but they are only capable of creating GL context for the default adapter.. However I am involved in HPC and GPGPU programming, and I was looking for a simple way to spawn OpenCL-OpenGL interop contexts on ALL the GPUs, even if they are off-screen, meaning there are no monitors attached and do rendering to textures. You can guess that you need to go elbow deep into the native APIs, and this is exactly the part where WinAPI proves it's worth. When you have to query low-level device IDs (display server), hand them over to the compositor, ask if the device is used on a screen, if not, create a new off-screen desktop... This is the part where it really matters whether the display server was designed by keeping the sompositor in mind, and how well they play together. X did not really help in the off-screen part. Even though I made friends with non-sense such as creating a dummy OpenGL context only to obtain the supported version, discard the context, then create a new one; I somehow lost my interest in GLX when I saw that pre-1.3 and post-1.3 API differs (the actual version might differ), and there is a completely alternate way to go about querying windowin extensions. This was the point I said: ah, just **** it. Off to Wayland.

Ultimately I ended up with Qt, even though I do not like depending on it, because it is too big. The compile-time OpenGL function wrappers are really nice and eventually, I can make friends with it, if it gets the multi-context job done for "free".

[kaprikawn]

KDE released an official notice that they would reject any patches to KDE for Mir less than 48 hours after Mir was announced based on that it was a single-distro's work. Amazing how that logic worked.

There are plenty of reasons why KDE might want to not accept patches that are not political in nature. For example, if someone submits patches, but then doesn't maintain them going forward, then the other devs would be stuck maintaining that code. Canonical has a reputation of not supporting upstream (rightly or wrongly). So rejecting patches on for this reason wouldn't be based on politics, but on available resources of the project. Also, what if they don't want to complicate their codebase with code that is specific to something which is only applicable to one distro? That would be a technical reason, not a political one.

[Veto]

But... does it run Steam?

Does Wayland run Steam?

That is no friggin answer! ....

No really, does it run Steam??? (In a useful way) If not... forget about it...

[finalzone]

That is no friggin answer! ....

No really, does it run Steam??? (In a useful way) If not... forget about it...

Have you read the reply on this topic?

[m132]

Main issue with Canonical, lack of manpower and making that kind of platform cost money.

Unfortunately, I have to agree..

Key difference is Apple does that with their specific devices they made themselves. Try doing it with devices using different specifications to realize that Apple will face similar issues, About the distributions, most of them choose either Red Hat Entreprise Linux or Ubuntu LTS, either Fedora/OpenSUSE or Ubuntu/Debian.

I'm not talking about drivers and hardware, but libraries and stable APIs. When you create a desktop notification on OS X, you can be sure, that it'll be displayed, meanwhile on Linux/X11, you have to worry if there's any process that handles these, will it be displayed correctly on each desktop environment, or even is there any D-Bus daemon running. Canonical is just trying to make Ubuntu predictable, just like Windows or OS X, so developer knows, that if his Ubuntu application creates a notification, it gets just displayed.

Canonical fixes turned out to be a hack. Unity is a massive pile of mess because porting it is still a nightmare due to Ubuntu specific implementation.

Because isn't meant to be ported. Is anyone complaining, because Android's SurfaceFlinger can't be run outside Android? Nope, and that's what Unity and Mir are for Ubuntu.

[Ancurio]

Hmm.. I see. I thought jo-erlend was confusing who (server or client) was responsible for drawing decorations into the buffer but it looks like I'm the one who was confused about this aspect of the Display Server. Still, I'm not sure I see significant difference here. Regardless of who "owns" the buffer memory (and, as other's point out, it can be either in Wayland apparently) you still use some API to render to it (EGL/OpenGL).. so how would a server-side allocated buffer be able to prevent rendering in any way a client-side allocated buffer would not? It seems the rendering API itself would be responsible for handling this "minized, don't actually draw" condition either way, not the Display Server. I'm genuinely curious now..

Also, I apologize for my tone, jo-erlend.

I was going to write up some contrived scenario in which the Mir server would instruct EGL to block on eglSwapBuffers().. but then I found this article explaining it beautifully: Because the client has to directly ask Mir for the next buffer when it's done rendering to the current one, it can simply get blocked on this get_next_buffer() call without EGL even being involved.

It also explains (some of) the reasons for why they chose the server allocation strategy in the first place (Android has the same strategy btw.).

[Ancurio]

Not really. The standard wl_shm interface allocates SHM buffers client side, yes, but where EGL buffers are allocates is entirely an EGL implementation detail. Mesa allocates them client side but other EGLs may allocate them server side, without the app or Wayland noticing a thing.

Ok, yes you're right, even though Mesa isn't doing it and none of the current desktop compositors are setup that way, in theory an EGL implementation on a completely different platform (like mobile) could secretly allocate things server side behind the clients back. However, I'm not sure how useful that would be.. I mean, isn't a big part of server allocation that the server can easily reapproriate costly buffer space from inactive to active clients, and maybe do things like single buffering instead of double when resources are extremely low? In Wayland, nobody can tell a client whether they should single, double, or penta buffer their surfaces, it would have to be negotiated.

[boxie]

The protocol is *defined* as XML but is *not* XML. That would effectively not be very performant for a local display server. Think of the XML as a schema, not the messages themselves.

Thanks to sandy.martel and Scias - I stand corrected (and I learnt something today!)

[Veto]

Have you read the reply on this topic?

You point to an answer that states XWayland can run Steam in an unplayable state.

Did I miss an answer with regard to XMir? And why do everyone try to divert the discussion to Wayland when I ask about Mir?

[duby229]

That would be me! Awesome how this fact is spread given that I never refused Mir patches, because there are none which could be refused.




Right as you say yourself it runs on Kubuntu as the reference platform. I'm pretty sure we mentioned it's running on Kubuntu and gave credit to that. Otherwise: it's not using Mir, but Wayland (even XWayland so X applications work). Yes, we might have provided more credit, but that applies to all the other projects we built upon.

But given the hatred comments of people like you I think it's a good idea to change to e.g. Debian as the reference platform.

Yes, please rebase on debian. That would be so freakin awesome. I have no doubt it would be complex and would require a lot of effort, but that would be fantastic. I know I hate on Canonical, but I'm not sorry for that. Debian would be a much more neutral base to build from. You'll probably have to rebase on debian anyway after snappy, so the sooner the better IMO. And I wouldn't even bother making snappy packages for KDE. If Canonical wants them they should make them themselves.