Wayland, Weston 1.2 Release Candidate Are Out

[mrugiero]

A system compositor is needed if you want seamless transitions between the login box and the desktop or when switching users and desktop environments, unless you start Kwin/Mutter very early and let them manage the login manager aswell (but then switching from KDE to GNOME wouldn't be seamless in this case). Since there's no "Wayland Server" running in the background to keep the display alive like on X, you need a system compositor to make the transition between the session ones.
AFAIK KWin will work as a session compositor with Weston as the system one. As Weston will most of the time only be displaying a fullscreen buffer there shouldn't be any overhead.

I don't really get why would you need that. The login screen doesn't need to be composited, you can as well use just a fullscreen app and bypass the compositor altogether. Then, the login screen calls the compositor. I think Wayland allows this.

[blackout23]

It beats me. I don't know if Weston allows the use of plugins or if the panel can be disabled (no desktop would want Weston's panel, but own instead). But yeah, I guess if those two can be done, it could be used as a standard base.

Like I said what makes weston look like a desktop is a module that get's loaded called "desktop-shell.so" referenced in the weston.ini as a module. There is also a tablet-shell.so that can be loaded instead which then handles the windows differently and doesn't have a panel afaik. Both are just C code and you can role your own.

From the wayland documentation it is clear that you don't need a system compositor. You can just aswell only have a session compositor.

A session compositor is responsible for a single user session. If a system compositor is present, the session compositor
will run nested under the system compositor. Nesting is feasible because the protocol is asynchronous; roundtrips would
be too expensive when nesting is involved. If no system compositor is present, a session compositor can run directly on
the hw.

[Awesomeness]

Seriously, which major distro is going too? I'm bored of waiting.

If wayland is so advanced and so far along and prefect in every way, such that the angels cry in its presense, why are you distros not installing it

Fedora's roadmap says that Fedora 20 will ship Wayland-compatible Gnome Shell and 21 will default to it: https://lists.fedoraproject.org/pipe...ch/180546.html
Look at the date. It is from March. What were you doing all these months? The info was out there all the time.

KDE (4.12 branch)

No 4.x branch will natively run on Wayland. KWin 4.11 only has experimental support for some Wayland features but cannot be used as full Wayland compositor (simply because Qt4 isn't really compatible with Wayland).
Proper Wayland support is in development for Plasma Workspaces 2 (which will be built on Frameworks 5 and KWin 5).
Martin Graesslin, KWin's main developer, posts updates about reached milestones every few days on his Google+ page.

Let's see, for *native* Wayland (the only thing that makes sense), mesa is not ready in upstream

Huh? I could've sworn that Mesa's Wayland back-end has been upstreamed long ago and is ready.

I fear a little bit for Openbox and the like. There wasn't too much activity on their repos lately, so I don't think they'll have the manpower to port to wayland anytime soon.

I don't think porting more bare-bone WMs to Wayland makes even sense. I think it would be better to take Weston and implement the features in it or a fork (the fork could be called OpenBox 4.0 or whatever).

One could say wayland is thought for higher end devices and the like, but one could as well use the simplest desktop possible while leveraging wayland.

I don't think one could say that Wayland is for higher end devices. If anything, initial development (incl. the design of Weston with client-side decorations) point to embedded devices. GENIVI uses Wayland for example: http://projects.genivi.org/ivi-layer-management/node/17

[Ericg]

Is it a bad idea to adapt weston to become the "standard" system compositor and use kwin/openbox/GNOME's/EFL's compositor as a session compositor? wouldn't that simplify much of the work the various DE's need to do? If not, why?

There actually were discussed plans for there to be a freedesktop.org project that did basically that did just that. No idea what ever CAME from those talks though...

[mrugiero]

Huh? I could've sworn that Mesa's Wayland back-end has been upstreamed long ago and is ready.

Maybe I recalled wrong, then. For XWayland I'm completely sure it's not upstream yet (at least not release by upstream, I have no idea if it's in the code repos).

I don't think porting more bare-bone WMs to Wayland makes even sense. I think it would be better to take Weston and implement the features in it or a fork (the fork could be called OpenBox 4.0 or whatever).

You are probably right.

I don't think one could say that Wayland is for higher end devices. If anything, initial development (incl. the design of Weston with client-side decorations) point to embedded devices. GENIVI uses Wayland for example: http://projects.genivi.org/ivi-layer-management/node/17

Didn't actually meant higher end as in high gamma, but as in newer versus older. I'm aware it runs in devices as low-end as the Raspberry Pi. I don't think if it would be wise, for example, to install Wayland on my old Unichrome powered box, since I have to make it run with LXDE to have decent performance. The drivers are probably to blame, though.
I'm aware that if anything, it would probably use less resources per app, but probably more altogether because of the multiple surfaces required for compositing.
EDIT: I forgot to clarify I'm comparing to non-compositing X. Against compositing X it will surely use less resources overall.

Like I said what makes weston look like a desktop is a module that get's loaded called "desktop-shell.so" referenced in the weston.ini as a module. There is also a tablet-shell.so that can be loaded instead which then handles the windows differently and doesn't have a panel afaik. Both are just C code and you can role your own.

From the wayland documentation it is clear that you don't need a system compositor. You can just aswell only have a session compositor.

Yes, I read it, but I had already posted. Thought of editing, but my severe laziness syndrome? stopped me.

[intellivision]

So the release number of a software depends on how many distro use it? This is new to me.
In any case I can answer to your question:
EFL
KDE (4.12 branch)
GNOME (3.10 branch)
Tizen IVI (3.0 branch) (announcement)
R-pi (next release branch)
and probably many others that don't bother to tell me if they use wayland or not.

All those releases will appear in the second half of this year, and *here* we are not speaking about an incredible stupid thing as a whole DE upon a compatibility layer, do you understand the difference? :-)

Heh, it's cute to see that some people still think Tizen has a future ahead of it when it clearly doesn't.
It's not FOSS, it doesn't know what toolkits its supposed to use, jumping from EFL to HTML5 and now an Android compatibility layer coupled with a closed source bada compatibility layer.
I mean, it's nice that they're trying out Wayland and all but it's not going to survive more than two years with the competition from better platforms such as Firefox OS, Jolla and Ubuntu Mobile.

[Awesomeness]

Heh, it's cute to see that some people still think Tizen has a future ahead of it when it clearly doesn't.
It's not FOSS, it doesn't know what toolkits its supposed to use, jumping from EFL to HTML5 and now an Android compatibility layer coupled with a closed source bada compatibility layer.
I mean, it's nice that they're trying out Wayland and all but it's not going to survive more than two years with the competition from better platforms such as Firefox OS, Jolla and Ubuntu Mobile.

Big words from someone too dumb to know the difference between Tizen Handset and Tizen IVI.

[Awesomeness]

Maybe I recalled wrong, then. For XWayland I'm completely sure it's not upstream yet (at least not release by upstream, I have no idea if it's in the code repos).

Just had a look. Wayland is part of upstream Mesa:

http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/wayland

No idea about XWayland or where to even look for the code. (Same with XMir, btw.)

[intellivision]

Big words from someone too dumb to know the difference between Tizen Handset and Tizen IVI.

One is for mobile devices, one is for computers in vehicles.
Both are based off the same codebase, and IVI is dependant on Tizen Mobile's success in order for it to survive beyond two years.
That said, Tizen mobile will probably never take off, which will leave IVI behind as an inevitable causality.

[AJenbo]

if for you major distro equals ubuntu only you are maybe right.

As example fedora a very popular distro if you watch.

if not I would consider non-enterprise major-distros would be ubuntu, fedora, opensuse, debian (even thats a bit enterprisy ^^), maybe mint, and maybe arch.

debian doesnt give a good example because it will get current software in 2 years. fedora and opensuse will not wait for nvidia to support wayland before they switch if they wait (maybe opensuse waits) its most probably not because of propriatary drivers but to experimental wayland support in gnome and kde...

arch will not wait too, and I am pretty shure even debian will not make its desition to include wayland or not up because of propriatary driver support. So only ubuntu that will support wayland not anyway directly will wait for propriatary drivers.

Or do you have another understanding what major distros are out there?

No i pretty much agree.