Keith Packard Comments On Valve Work

[indepe]

More work on the display stack from a gaming developers perspective should become very beneficial overall.

[finalzone]

At the end of the they improving/fixing X issues is the way to go. Too many software depends on it, new software isn't always the best solution.

There is nothing to improve X server as XWalyand allows backward compatibilty. Focusing improving toolkit supporting Wayland protocol is a priority and software will need to adapt.

[gwgwg]

But it is still 6-12 months from becoming the default in the Linux ecosystem. And that's assuming they can get all the functionality of x in there.

They are far, far away from supporting fundamentals like color management, and not even heading in a direction that will accomodate it. So get used to needing X11 for a long time to come if color is at all important to you.

[gwgwg]

There is nothing to improve X server as XWalyand allows backward compatibilty.

No it doesn't. Things like XRandR access, root atoms etc. are not supported by XWayland, and this breaks important stuff like Color management.

[liam]

This is weird. We've already got (or it's being worked on) fine grained frame timings via: wl_surface::frame callback (ms granularity - it's a bit ill defined but gone use it to compute), wp_presentation::feedback (returns an object with lots of info including when the frame is presented), egl_KHR_fence_sync (this might be better seen as a mechanism, i guess), lastly we have dma_sync & sync_file structs (adapted from Android's sync framework and, i think, only i915 has implemented this, so far).

[M@yeulC]

This seems like a practical move to me. SteamOS currently uses X, the developers develop for X, It'll be a while before Wayland is defacto.

For SteamOS, they stated that they considered it, but that they decided against, as there were no obvious benefits. That could be one. That said, I don't know enough to tell whether the frame timing reporting is already part of Wayland or not.

A world-class product needs zero-bullshit just-works software.

Wouldn't that be an argument in favor of Wayland? :P
By the way, Wayland already shipped on countless products last time I heard about it, from smart TVs to vehicle infotainment systems to smartphones. And in my experience, the protocol is much cleaner and easy to use than the old X protocol.

No, today, the only thing that's keeping us on X is legacy and inertia (porting a fully-fledged compositor or desktop environment takes time). XWayland works pretty well, and most games use SDL2 anyway, which has Wayland/mir support. I think that valve could switch if they wanted.

Now, the real question is: do they actually have an incentive to switch? Since they more or less control app distribution on SteamOS, and it is not (intended as) a regular general-purpose OS, security is less of a concern. The "every frame is perfect" goal is also a bit less relevant. I can see some advantages, though.
I would be curious to see some X-vs-Wayland benchmark, it has been a while since I last saw some.

[ElectricPrism]

For SteamOS, they stated that they considered it, but that they decided against, as there were no obvious benefits. That could be one. That said, I don't know enough to tell whether the frame timing reporting is already part of Wayland or not.


Wouldn't that be an argument in favor of Wayland? :P
By the way, Wayland already shipped on countless products last time I heard about it, from smart TVs to vehicle infotainment systems to smartphones. And in my experience, the protocol is much cleaner and easy to use than the old X protocol.

No, today, the only thing that's keeping us on X is legacy and inertia (porting a fully-fledged compositor or desktop environment takes time). XWayland works pretty well, and most games use SDL2 anyway, which has Wayland/mir support. I think that valve could switch if they wanted.

Now, the real question is: do they actually have an incentive to switch? Since they more or less control app distribution on SteamOS, and it is not (intended as) a regular general-purpose OS, security is less of a concern. The "every frame is perfect" goal is also a bit less relevant. I can see some advantages, though.
I would be curious to see some X-vs-Wayland benchmark, it has been a while since I last saw some.

I agree with your reasoning.

I think that there is clearly lack of reasons or benefits to make such a switch.

On the other hand, I think that waiting it out will simply let everyone else in the industry get better at wayland which will make the cost of labor decrease as wayland becomes more common.

It's pretty much the same principle as to why some companies prefer Linux to FreeBSD - it's easier to hire qualified Linux System Admins. Supply & Demand plan and simple.

I think simplicity is often a goal of any well crafted commercial product so I anticipate one day they will upgrade and default - especially if there is a performance advantage or driver advantage or stability advantage, etc...

Our SteamOS Machine is rock solid, I want to get 2-5 more as I prefer the "No Bullshit" approach to having my games work regardless of X package update.

[Ardje]

Valve is planning on shipping or at least announcing VR games this year already. There's no way Wayland can mature enough for Valve to put all their eggs in that basket. Better go with what's stable and working.
(Also, Wayland will never "get" all the functionality of X)

Actually, it sounds they are making a wayland thing in X :-).
And yes, I am desperate to run wayland to make things smoother, and yes, x-on-wayland works
Except for gles :-(.
I will probably never be able to say goodbye to X since it is so networked it is needed.

[nomadewolf]

Depends on who you ask. For me, it was perfectly usable since 3.0, no issues with functionality or stability. Others would argue it's still not there...

Yes.
For me, it's still not there, nor i see light at the end of the tunel.
The whole UI is so dumbed down that i feel like i'm using a Mac...

[Masush5]

Please inform yourself properly: mpv does NOT use these obsolete SGI extensions by default! Only when using GLX (instead of the better EGL) & activating "waitvsync" are they used (which is not recommended, by the way!).

Ok I was unaware the SGI extensions were only used when activating waitvsync, but on amd mesa it still defaults to glx and there is no hardware decoding available when running under egl because the vaapi egl interop is not implemented for gallium.