Canonical Shows Legacy X11 Apps Running On Mir With Unity 8

[doom_Oo7]

PS: ...and did i forgot to mention, again, almost ad nausea , that xWayland was considered a TEMPORARY solution and would be DITCHED sooner or later ?
That what was said in the begin of the project in some slides of a presentation.

I think that this was meant in the same way that 32 bit support in windows, i.e. one day it will go but this day is still decades away (took 20 years to ditch 16bit support).

[F i L]

Please, only start flaming if you have ever written code to open a Window with an OpenGL canvas with native OS bindings. With WinAPI, it is as easy as 1-2-3, and with X and GLX, it is practically a joke. Ultimately it all boils down to how well the display server and the compositor play together. If you develop both in-house, you can come up with a far better API, than trying to be a generic, flexible and all library.

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.

[Krejzi]

...and you just confirmed that NONE of the alternatives to X is ready....and possibly will never will for older (including AAA) games (i.e. ET:QW) that will NEVER be ported to Wayland or Mir.

Don't worry, that's just a part of wayland that hasn't been touched yet, given that there were far more important things to worry about. X apps do pointer locking/grabbing in very ugly ways. raster of Enlightenment and pq of Collabora just explained that to me on IRC.

Note that no wayland app can yet lock a pointer properly due to missing protocol and compositor support and Xwayland is just another Wayland app. Until that's implemented, it's a no-go. There are some WIP patches by Jonas Adahl (forgive me if I wrote the name wrong) that add the necessary protocol and compositor stuff to get that working, but it's taking a damn long time to get it properly reviewed and everyone happy.

[blackout23]

I Really thought they where further along in the development of XMir.
Please remind me again... Why didn't they just use Wayland?

Because REASONS!!

[Ancurio]

I took a glance at Wayland a long time ago, when I was looking to writing a small OpenGL windowing library, and thought Wayland will be my salvation out of XHell. Having implemented the Windows side in 200 LoC, when the X version reached 800, I abandoned it and went for Wayland. I peeked into the documentation, and very visible "WTF" signs were floating above my head. Why do I have to jump through fiery hoops to obtain a ****ing OpenGL context?!

I mean, 95% of GL context bring up on Wayland is using EGL.. wl_display is your Native Display Type and wl_egl_window is your Native Window Type. You're basically saying that the standardized Khronos API for the task is too complicated. Why even use OpenGL in the first place?

[Ancurio]

Wtf.. where are you getting this? You tell a guy to stop spreading rumors about Mir's CLA and then in the next comment you say things like this?

Also, Wayland itself has nothing to do with client-side vs server-side buffer management (if I even understand what you're getting at by that).. that's entirely up to how the specific Wayland Server/Compositor handle Window Decorations (for instance KDE's Kwin's Wayland backend will handle decorations server-side last I heard, while Gnome's and Weston do it all client-side). And Wayland Compositors can be just as optimizationed as any Mir Compositor can. The only real difference is that one is designed to be an extensible protocol useful to more than just a single group's desktop environment. Please take your own advice and stop spreading rumors.

Wayland most definitely has a notion of buffer management, and the person you quoted is correct. On Wayland, buffers are allocated by the client, then shared with the compositor over the wire by their handles, whereas in Mir they are allocated by the server/compositor. That is a technical fact, and I have no idea why you're dragging window decorations into this as they have absolutely nothing to do with it.

[giucam]

Wayland most definitely has a notion of buffer management, and the person you quoted is correct. On Wayland, buffers are allocated by the client, then shared with the compositor over the wire by their handles, whereas in Mir they are allocated by the server/compositor. That is a technical fact, and I have no idea why you're dragging window decorations into this as they have absolutely nothing to do with it.

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.

[oleid]

They want a display server. Wayland is designed not to have one. There's been speculation that you could use the Wayland protocol to build a display server, but noone has shown one yet, so it's just a hypothesis. Wayland is designed for client side buffer allocation, whereas Mir is designed for server side buffer allocation. That's as opposite as it gets. It's not obvious that using Wayland for this would've been beneficial.

The wayland protocol doesn't specify where the buffers are allocated. It's up to the compositor. weston on kvm/mesa just happens to allocate them on the client side. Actually, weston on raspberry pi allocates them on the server side.

[F i L]

Wayland most definitely has a notion of buffer management, and the person you quoted is correct. On Wayland, buffers are allocated by the client, then shared with the compositor over the wire by their handles, whereas in Mir they are allocated by the server/compositor. That is a technical fact, and I have no idea why you're dragging window decorations into this as they have absolutely nothing to do with it.

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.

[andre30correia]

canonical wants to control their display server, nothing more, their choice, stop with this stupid hate..