Sorry for the slow follow-up, but for whatever it's worth everything seems to work fine on a PRIME setup, even without D23881. No tearing, no hangs when rendering QtQuick pop-ups, and subjectively, latency when dragging windows, ect., feels about the same as before. So maybe the fall-back timer on NVIDIA hardware is good enough.

Also, apart from the above two comments, any thoughts to how this relates to Roman's pending re-work of a lot of the GLX code https://phabricator.kde.org/D23105?

Regarding the fallback to the composite timer when using the proprietary NVIDIA driver, while it doesn't really support anything equivalent to GLX_INTEL_swap_event, there is https://www.khronos.org/registry/OpenGL/extensions/NV/GLX_NV_delay_before_swap.txt which has the similar goal of reduced input latency. See the extension description for details, but essentially it allows the application to block until a specified time before the next swap. I'm not sure if that's exactly fits what KWin needs here, but maybe worth considering?.

Use QQuickWindow::setSceneGraphBackend instead of setting environment variable

This might serve as a preferable alternative to reverting the tearing fix 22a441e071515e9c630f3bdac743c678052f88be for 5.12.

There was mention of switching QtQuick to use SW rendering on PRIME systems, would that be preferable to reverting the tearing fix?
I just learned that RandR will report a property named "PRIME Synchronization" for any affected outputs, so it should actually be easier than I originally thought to detect. Just need to call XRRListOutputProperies (or whatever the xcb equivalent is).
I can try to get a quick patch up for review if so.

alphabetized #include statements

added brief explanation comment

I posted a comment on the bug (shall we just move this discussion there going forward?) with a bit more explanation, but in summary David's patch seems to only prevent the hang the first time a QtQuick window is displayed. However, I think this might be more of a Qt issue that might be worth fixing upstream, although maybe it can be worked around in KWin as well. I'm not sure to what extend Qt and KDE development is coordinated?

Alright, I think I see what the issue is. For context, on PRIME systems, since there isn't actually a display connected to the NVIDIA GPU, we rely on xf86-video-modeset, which drives the Intel GPU, to call to our driver after each vblank. However, it will actually only do so if there has been damage to the screen. So what I think we have here is QtQuick's thread waiting on this vblank signal before swapping buffers (since we set MaxFramesAllowed to 1), and KWin's main compositing thread waiting on the QtQuick thread. Since KWin isn't rendering to the screen while it waits, no damage occurs and hence this vblank signal is never sent. I think some timeout is what eventually gets things going again (after about 30 seconds). Does that make sense?

Curious, sorry for overlooking PRIME systems in my testing. Since the QtQuick window would be redirected, MaxFramesAllowed=1 should have the effect of forcing glxSwapBuffers to wait until rendering for the previous frame has completed and the back buffer contents have been copied to the front buffer. I'm taking a look into this internally as well, having access to a debug NVIDIA driver might provide some more insight into what's going wrong. Will update with any progress, hopefully we can avoid having to revert the fix.

Changed the dynamic_cast in create() to static_cast. Since the Private is created in the constructor of EglStreamControllerInterface, it should be safe to assume it is of the correct type.
Also marked Private as Q_DECL_HIDDEN.

Ok, now we will bail out early during create() if we fail to dynamically load the interface (before calling wl_global_create). The compositor can then use isValid() to check if whether creating the interface succeeded or not, it will also print a warning if it fails. Unfortunately, as Roman has pointed out, since Global::create is not virtual the compositor technically *could* still break things by calling the parent class method, but I'm not sure if it's worth changing that for just this one somewhat special case, especially considering that this will probably only ever actually be used by KWin's EGLStream backend anyway.

In D18824#448597, @romangg wrote:

In the first revision the interface failed to create when the dynamically loaded library was not present (we said the class should always be created though). Now it just fails silently on bind. Why is it ok to fail silently on bind?

Re-added protocol XML file to diff and corrected version in display.h

removed C-style casts

Awesome, just waiting on a final sign-off for https://phabricator.kde.org/D18824 and I'll get both checked in.

In D18570#410243, @davidedmundson wrote:

My blur's are missing, and I get a crash when the internal QPA creates a new GL surface over internal QOpenGLFramebufferObjects.
You'll see when you press alt+tab and it's set to show a dialog (https://phabricator.kde.org/P313)

In D18570#434275, @davidedmundson wrote:

What's our plan for the EGL_TEXTURE_FORMAT issue? Simply to implicitly depend on the new driver?

I'm hoping this bug, along with the tool-tip issue, might be considered minor enough to not warrant holding up the show until we can get fixes out (which should be soon). The desktop is still essentially usable with them present, right? And the backend already depends on a fairly recent version of the driver with support for all of the required EGL stream features (some of which are fairly new).

In D18376#407857, @davidedmundson wrote:

Instead of emitting cursorChanged from DrmBackend, modify SceneOpenGL to connect Platform::cursorChanged as opposed to Cursor::cursorChanged to the cursor texture update function.

Where does the platform emit cursorChanged?
On wayland the only place I can see that emits Platform::cursorChanged is connected to CursorImage::changed

Sorry for the delay, but the new backend now integrates into the atomic modesetting path of DrmOutput::present eliminating the need to expose the internal pageFlipPending flag and is a bit cleaner in general, I think. It leverages the existing code for modesets (which are now actually working correctly), however page flips are still performed through EGL. This necessitated adding an early return from DrmOutput::presentAtomically as well as not registering the flip event when using the EGLStream backend. I tried to make this as minimally-invasive as I could, and since there's already a fair amount of coupling between DrmOutput and DrmBackend hopefully a little bit more isn't the end of the world. Modesets use an empty dumb buffer, which is the same strategy that Mutter and Weston's EGLStream backends employ.

In D18570#416210, @davidedmundson wrote:

And I was not talking in my review comments about superficial stuff,

We're just talking about the use of DrmOutput::present, right?
We could make a fake DrmBuffer instance round that doesn't do anything - and add some property in DrmBuffer to indicate whether we perform the relevant DRM calls or not. Would you prefer that?

@erik
One difference missing is that when we change modes we delay it till the DrmOutput::presentLegacy and then call drmModeSetCrtc with the pending buffer handle.
Right now as far as I can see any type of mode switching is missing.

Is that in the KWayland master branch? In the file I'm looking at buffer_interface.cpp:152 is in the middle of a switch statement in the constructor.

Updated diff against HEAD

In D18570#408853, @romangg wrote:

First off: a driver not supporting Atomic Mode Setting is nothing modern. Does Nvidia has a plan to improve in this regard?

I'm really not happy, that the DrmOutput::present is not run and we have to export these internals from DrmOutput to the EglStreamBackend, which replaces the flip with an EGL function call. Why does the Nvidia driver not integrate with the libdrm API in regards to page flipping? It should be possible to at least offer a wrapper around it or not?

• Fixed style issues in drm_backend.cpp / drm_output.h
• Switched surface -> texture map to use SurfaceInterface pointers instead of wl_resource pointers
• Moved eglQueryWaylandBufferWL to egl_stream_backend.cpp
• Added support for receiving stream attributes from EglStreamControllerInterface (currently unused by the driver, but good for future proofness).

Thanks for taking a look, Roman. I've addressed your style suggestions and added support for passing stream attributes to the compositor. I had ignored these initially since the driver doesn't actually use this (fairly new) feature of the extension right now, but it probably is best to support it for future-proofness.

Oh yeah, I've seen similar backtraces to that as well, actually. I think it's because QT is trying to share between an OpenGL context and an OpenGLES context. I don't think it's related to the compositor, though. It also occurs on GNOME and the weston eglstream port. I'm not sure if it's a QT bug or NVIDIA driver bug but I'll look into it a bit more as well.

Use a KWayland wrapper around wayland-eglstream-controller instead of binding the interface from KWin. This avoids having to link against Wayland libraries. Depends on revision https://phabricator.kde.org/D18824 implementing the required KWayland class.

Replaced dlopen / dlsym with QLibrary::resolve to avoid having to link against dl
Fixed a few more style issues
Added KWIN_BUILD_EGL_STREAM_BACKEND CMake option to control whether the new backend is built (defaults to ON).
Changed the name of the environment variable to KWIN_DRM_USE_EGL_STREAMS (instead of EGLDEVICE) to be a bit more consistent.

Instead of emitting cursorChanged from DrmBackend, modify SceneOpenGL to connect Platform::cursorChanged as opposed to Cursor::cursorChanged to the cursor texture update function.

Added context to the diff and fixed style issues, (thanks the feedback)

In D18570#401368, @hein wrote:

If I blacklist the kscreen2 kded module, I can get the session to start (otherwise it crashes during the splash). However, all surfaces (e.g. the panel or krunner) don't react to mouse clicks and seem frozen-ish.

BTW, while playing around with this I noticed that kwin_wayland doesn't work in windowed mode on X when run on nVidia EGL, due to the driver not implementing GL_OES_EGL_image.

Thanks for taking a look, David. Regarding your suggestion, do you think it would make more sense then to connect Platform::cursorChanged to the texture update function in scene_opengl.cpp instead of Cursor::cursorChanged? I'm not entirely clear on the distinction between those two signals, but the former does get emitted when the cursor changes while it seems the latter does not at the moment.

In D18307#394965, @zzag wrote:

@ekurzinger Do you have commit access?

Hi David, thanks for taking a look! Note that I haven't got commit access so I believe someone will need to merge on my behalf. For authorship information, my name is Erik Kurzinger and email is ekurzinger@nvidia.com.

In D16278#346177, @graesslin wrote:

In D16278#345365, @zzag wrote:

The freeze is still intermittent, but using this method should be able to be triggered within about 10 tries without this fix.

Well, I wasted hours trying to reproduce the bug with no luck.

So did I! Good job.

Sure, I have a single dolphin window positioned in the top-left corner of the leftmost desktop with dimensions 750 by 500. For some reason, the tool-tip for the "Split" button seems to be the most consistent way, but maybe that's just my imagination.
I have a single 1920x1200 monitor, and 3 virtual desktops in a single row. I've attached my kwinrc file in case there's anything else relevant there. Animation speed is set to 4, and the compositor backend is set to OpenGL 3.1

Hi Vlad,