Fedora 25's Hybrid Graphics Improvements, To Support NVIDIA Wayland EGLStreams

[blackout23]

How did you even manage to run Weston on NVidia's proprietary driver? AFAIK they didn't accept NVidia patches to run weston with EGLStreams.

By just applying these patches myself obviously. I compiled the wip/egldevice branch of mutter with --enable-egl-device and I'm currently writing this from a Wayland session using the proprietary NVIDIA driver. I thought GNOME/Wayland had a hard dependency on Xwayland still and since Xwayland doesn't work with NVIDIAs driver, yet I thought that this would keep GNOME on Wayland from even starting. I can see that /usr/bin/Xwayland still was started by /usr/bin/gnome-shell.

[ciupenhauer]

By just applying these patches myself obviously. I compiled the wip/egldevice branch of mutter with --enable-egl-device and I'm currently writing this from a Wayland session using the proprietary NVIDIA driver. I thought GNOME/Wayland had a hard dependency on Xwayland still and since Xwayland doesn't work with NVIDIAs driver, yet I thought that this would keep GNOME on Wayland from even starting. I can see that /usr/bin/Xwayland still was started by /usr/bin/gnome-shell.

So you can already open a gnome session? whoa, thought it didnt work yet. Hows the shell performance?

[blackout23]

So you can already open a gnome session? whoa, thought it didnt work yet. Hows the shell performance?

Works great. GNOME shell was never "slow" on my PC. Only thing I have to figure out is how to make it use my custom 96Hz EDID for my 1440p monitor. On X.org that's trivial witht he CustomEDID option. The drm.kms_helper kernel module option doesn't seem to work for me.

[fuzz]

I wish open source devs wouldn't let proprietary companies bully them into support. Innovation and change is a good thing, but only if you play nicely.

[Hi-Angel]

I wish open source devs wouldn't let proprietary companies bully them into support. Innovation and change is a good thing, but only if you play nicely.

Well, the particular EGLStreams vs GBM story seem gonna have a happy final of "Unix Device Memory Allocation", from which would benefit everyone.

[89c51]

I wish open source devs wouldn't let proprietary companies bully them into support. Innovation and change is a good thing, but only if you play nicely.

The weird thing is that many devs don't seem to like ar consider eglstreams a proper solution. Yet gnome goes on to support it. AFAIK the other DEs won't follow. I hope however that this wont affect the development of the new solution. Which is needed yesterday.

[karolherbst]

Well, the "maximum operating temperature" for a random haswell CPU is 72.72℃. Anyway, I just wanted to say that, AFAIK, usually at 100℃ CPU shuts down itself.

that's desktop.

my CPU: http://ark.intel.com/products/75117/...up-to-3_40-GHz and on my system the CPU is at 98, 99°C at full load, but this is pretty normal on mobile CPUs.

[AdamW]

Just a quick note - the Test Day is not going to cover any of the NVIDIA proprietary driver stuff. It's all still very much in progress, and frankly, I don't know enough about how it's all supposed to work and which bits of it are supposed to be working *right now* to write useful tests. The Test Day will cover open source driver cases only.

[Awesomeness]

Where are all the people that were saying EGLStreams in Wayland is not going to happen?

For now those are downstream patches by Red Hat that have yet to be accepted upstream. And even if they land in Gnome at some point, if the Wayland developers accept the same for Weston is an entirely different debate (especially considering that the other stakeholders in Wayland, Intel and Samsung, have nothing to gain from special treatment for NVidia). Similar with other, non-Gnome Wayland compositors like Qt's or KWin.

That said, apparently some compromise has been reached last XDC, although I have to confess I didn't read up on it in detail.

I wish open source devs wouldn't let proprietary companies bully them into support. Innovation and change is a good thing, but only if you play nicely.

Well, seems like NVidia is important enough for Red Hat's commercial RHEL customers, so they jump through hoops.
I'm very surprised by that announcement as well but I also didn't take Red Hat's business interests into account when I was among "all the people that were saying EGLStreams in Wayland is not going to happen" (I based my conclusion on the fact that lots of rewrites are needed to support NVidia/EGLStreams and the blog post confirms that it's a lot of work). Now I wouldn't be surprised any longer if at least Qt's built-in Wayland compositor will gain EGLStreams support as well.

[Awesomeness]

Fuckin unapproved bullshit. Again:

Where are all the people that were saying EGLStreams in Wayland is not going to happen?

For now those are downstream patches by Red Hat that have yet to be accepted upstream. And even if they land in Gnome at some point, if the Wayland developers accept the same for Weston is an entirely different debate (especially considering that the other stakeholders in Wayland, Intel and Samsung, have nothing to gain from special treatment for NVidia). Similar with other, non-Gnome Wayland compositors like Qt's or KWin.

That said, apparently some compromise has been reached last XDC, although I have to confess I didn't read up on it in detail.

I wish open source devs wouldn't let proprietary companies bully them into support. Innovation and change is a good thing, but only if you play nicely.

Well, seems like NVidia is important enough for Red Hat's commercial RHEL customers, so they jump through hoops.
I'm very surprised by that announcement as well but I also didn't take Red Hat's business interests into account when I was among "all the people that were saying EGLStreams in Wayland is not going to happen" (I based my conclusion on the fact that lots of rewrites are needed to support NVidia/EGLStreams and the blog post confirms that it's a lot of work). Now I wouldn't be surprised any longer if at least Qt's built-in Wayland compositor will gain EGLStreams support as well.