- User Since
- Oct 15 2018, 5:53 PM (34 w, 6 d)
Fri, Jun 14
added brief explanation comment
May 13 2019
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?
May 8 2019
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?
May 6 2019
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.
Apr 15 2019
Apr 12 2019
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.
Re-added protocol XML file to diff and corrected version in display.h
Apr 11 2019
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.
Apr 10 2019
Mar 22 2019
Mar 20 2019
Mar 19 2019
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).
Mar 18 2019
Mar 13 2019
Mar 12 2019
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.
Feb 22 2019
Feb 20 2019
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.
Feb 19 2019
Updated diff against HEAD
Feb 14 2019
- 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.
Feb 12 2019
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.
Feb 11 2019
Feb 8 2019
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.
Feb 7 2019
Jan 31 2019
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.
Jan 30 2019
Instead of emitting cursorChanged from DrmBackend, modify SceneOpenGL to connect Platform::cursorChanged as opposed to Cursor::cursorChanged to the cursor texture update function.
Jan 29 2019
Added context to the diff and fixed style issues, (thanks the feedback)
Jan 27 2019
Jan 22 2019
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.
Jan 18 2019
Jan 17 2019
Jan 16 2019
Oct 26 2018
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 email@example.com.
Oct 25 2018
Oct 20 2018
Oct 17 2018
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