mutter and wayland on mageia?

[PietroTux88]

i have listen on web about mutter and wayland replacement of compiz and xorg 2 items news for change of dists. If we of users mageia have mutter and wayland? soon on mageia?

[wobo]

I don't know about mutter. Wayland has a long way to go until it will be a stable part of any distribution.

[Sfiet_Konstantin]

Mutter is the compositing lib used in Gnome 3 (AFAIK).

[rickst29]

I know a tiny bit about these things. (Not a lot!) Much more than the Window Manager (which doesn't have to be a compositing WM in either case), you're talking about the GUI Toolkits underneath. For most programs, these will be GTK 3.x and Qt 5.x.

In the land of GTK, AFAIK, it's planned to let you Build with some choices. If you use X11, then the API for input events will probably have to be XI 2.1. (Although 2.1 is not officially "stable", because API changes are being made, you wouldn't want to stay on XI version 2.0. This is because there are API/Protocol fixes, and code to implement them, which you really, REALLY want to have. (They involve things like touch devices which support mouse "pointers" running concurrently.) GTK 3.x is in pretty good shape on this "alternate Backends" situation. Qt 5.x, OTOH, is nearly certain to be built with a Wayland backend exclusively. Why?

Because, in practice, X.Org has 25 years of backwards compatibility to maintain, and the protocols contain a number of "timing gaps" which create lost data and lost events. Qt technical guys feel that Wayland will probably be more reliable and complete, for their first release. But that's well into 2012, which I'll SWAG to be at least 3 Mageia Releases away.

There are definitely issues with mixing XI 1.x and XI 2.x. (In short, don't do it.) But I don't why, or exactly what they mean when they say that. Myabe they're referring to Windows within a single application; or applications controlled by a single Toolkit; or all applications running on a single WM instance; or the ENTIRE instance of an X11 Session. I've got other things to worry about. In the very, VERY long term, wayland probably wins.

BTW Qt 5.x does not imply a radically different KDE environment. The first Release which requires Qt5 underneath might even be Released as a part of the "4.x" series.

[Sfiet_Konstantin]

Qt 5.x, OTOH, is nearly certain to be built with a Wayland backend exclusively. Why?

...

BTW Qt 5.x does not imply a radically different KDE environment. The first Release which requires Qt5 underneath might even be Released as a part of the "4.x" series.

I also now a little about Qt 5.x.
There are numerous discussions on Qt 5, but it is said that Qt 5 will try to target the widest range of platform. They have a project called "Lighthouse" that make porting Qt easier.
AFAIK, Qt 5.x will support both X11 and Wayland.
The only "problem" with Qt 5 is it's dependencies to OpenGL. Because all drawing operations will be done by using OpenGL, I'm quite afraid of free drivers support, or even proprietary drivers.

Qt 5.x will also be source compatible with Qt 4.x program (well, it tries).

[rickst29]

Qt 5.x, OTOH, is nearly certain to be built with a Wayland backend exclusively.

Why? ....
I also now a little about Qt 5.x. There are numerous discussions on Qt 5, but it is said that Qt 5 will try to target the widest range of platform. They have a project called "Lighthouse" that make porting Qt easier. AFAIK, Qt 5.x will support both X11 and Wayland.
The only "problem" with Qt 5 is it's dependencies to OpenGL. Because all drawing operations will be done by using OpenGL, I'm quite afraid of free drivers support, or even proprietary drivers.

Qt 5.x will also be source compatible with Qt 4.x program (well, it tries).

I'll cover Wayland first, because a complete answer is... a little complex.

X11 versus Wayland affects both the input side (mice, pens, keyboards, touch, multitouch, etc.) AND the output window (hardware and low-level API). In my tiny, tiny bit of work within Qt, I have been focusing on the input side, and you could be correct about the terminal screens... although use of X11 would be a mistake on any box where Wayland is already present (for input).

For input, it is felt by the full-time Devs to be more difficult to "migrate" the X11 interface code from the "X Input Protocol" Version 1, (AKA "XI 1.x") to the version that will be necessary for "the future". (Including "proper" Multitouch, AND multiple pointers sharing the same Screen/Window/Application.) The required version would be "XI 2.1", still undergoing Development, with an unstable API. Qt4, like all it's predecessors, is built against XI 1.x. The number of interfaces is enormous, and Qt keeps stumbling into trouble when (for example) "Pen" devices have "too many buttons".

Or even mice, which has (unfortunately) become an unpleasant specialty of mine. The XI 1.x button mask field is only a single byte, and thus (obviously!) you can't see the full set of pressed/unpressed button states. Even worse, within qt, the entire definition of "possible buttons numbers" is defined by a single byte. (You would have a maximum of only 3 buttons, if Qt didn't separate the 4 wheel motions into a separate API. So, with WHEEL-UP, WHEEL-DOWN, SCROLL-LEFT, and SCROLL-RIGHT excluded, there are 7. Oddly, we define only 5 of them (BUTTON1, BUTTON2, MIDBUTTON, and the ones which should have been called BUTTONBACK and BUTTONFORWARD, named XBUTTON1 and XBUTTON2.) But for people with a "gamer" mouse like mine, adding just two more doesn't help much -- the "extra" buttons which are easiest to click on my mouse have even higher numbers, and there are a lot of them.

XI 2.1 (and 2.0, for that matter) provide no less than a 32-bit mask field in the event. For buttons on "mice", X11 probably can't go past #31. But the API is radically different- instead of a gigantic number of function signatures, each utilizing a fixed set of parameters, and most dedicated to a particular KIND of device, there are very few. (Instead of having one set of functions for the "mouse" and another set of functions for the "pen", the type of device, and even the type of event, are parameters within a very small number of function/event signatures. The most clever thing, IMO, is allowing the size of the input/ output parameters to vary: If there ever was a "mouse-like" device with 40, or 70 "button states" which needed to dealt with, be shown, it would use the same API. But the length of the vector for buttons, rather than being fixed at 32 bits, can be built with additional CARD32 elements to contain the rest of the data. In the case of events from X11, they're built on-the-fly, so the Qt-X11 interface would need to be re-written to release them.

Fundamentally, the data comes from the evdev driver. Wayland uses the same driver, but connects the Client Application to the X11 devices more directly. (X11 is fundamentally a REMOTE protocol, even if the Application is running in the same "box" as all of the hardware.) It is far more simple, and may very well be more stable at an earlier date. Within Qt, the X11 input migration is probably harder! than the Wayland migration.

[Sfiet_Konstantin]

Wow, how interesting is this
So you think that Qt 5 will have a better support for wayland, and will be considered "done" or "depreciated" for X11.
It is kinda sad for this toolkit that wants to target the widest range of devices / OS ...
(They also interupted support for AIX Solaris and others **x)

And do you think that wayland is mature enough ? It might be Ok for daily usage, but for example, for graphically accelerated games / compositors, missing proprietary drivers might be a huge handicap, no ?

[eugeni]

If you are curious about wayland state now, it is running pretty fine on my machine, but it still has a long long way to go to become something similar to X replacement for casual human beings (http://dodonov.net/blog/2011/06/11/x-or ... vel-stuff/).

If you want to play with it, I can share some rpms/srpms, but this is git-based stuff. Be warned .

[doktor5000]

If you want to play with it, I can share some rpms/srpms, but this is git-based stuff. Be warned .

Hey eugeni. THAT would be really nice if you could provide these src.rpm packages to experiment with