[kdeconnect] [Bug 419897] Error when accessing filesystem. sshfs finished with exit code 1
https://bugs.kde.org/show_bug.cgi?id=419897 Erik Kurzinger changed: What|Removed |Added CC||ekurzin...@gmail.com --- Comment #33 from Erik Kurzinger --- Also encountering this issue after an update. It looks like the sshfs command is failing with the following error message... fuse: unknown option(s): `-o ssh-rsa' If I modify plugins/sftp/mounter.cpp and delete the "HostKeyAlgorithms=+ssh-dss\\,ssh-rsa" line then it works again. Maybe sshfs or fuse changed how they parse options and is now getting confused by the comma? But it's not entirely clear to me why this option is even necessary. It is for compatibility with older systems or something? -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 471559] Wayland plasma session does not get along with egl-wayland 1.1.12
https://bugs.kde.org/show_bug.cgi?id=471559 --- Comment #2 from Erik Kurzinger --- I've determined that this is a bug in the NVIDIA EGL library. Kwin is not doing anything wrong, we're just not correctly processing the dma-buf feedback that it sends us. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 471559] Wayland plasma session does not get along with egl-wayland 1.1.12
https://bugs.kde.org/show_bug.cgi?id=471559 Erik Kurzinger changed: What|Removed |Added CC||ekurzin...@nvidia.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450914] Wayland, games on Nvidia are force vsynced
https://bugs.kde.org/show_bug.cgi?id=450914 --- Comment #25 from Erik Kurzinger --- So I did look into this a bit further, and can provide some hopefully relevant information... Firstly, I noticed that, unfortunately, direct scan-out for Xwayland applications doesn't work at all with our driver right now. This is an issue on our end, we're allocating compressed buffers which aren't eligible for scan-out. It should be pretty easy to fix, but that will need to be in an upcoming driver release. Pertaining to the issue at hand, though, that implies Kwin's direct scan-out behavior is not relevant. Xwayland applications will always be composited. To follow-up on Zamundaaa's earlier comment, the difference between Mesa and NVIDIA does indeed appear to be due to the fact that Mesa will use 4 buffers in its swapchain if vsync is disabled and the Present extension reports it's using the flipping path. Our driver, on the other hand, will only use two, always. Note that's only for X11 applications with Xwayland, for native Wayland applications we do actually use 3, and, at least in my testing, those aren't capped to the display refresh rate. I experimented with increasing the number of swapchain buffers to 3, and using mailbox-style logic similar to Mesa, and this does resolve the issue. So that is an option. However, I still question why Kwin is holding on to both buffers for the entire frame if it's not doing direct scan-out. Like, if we do two wl_surface_attach/damage/commits in a single vblank period, shouldn't the second one cause the first buffer to be released? That's what happens with weston, mutter, wlroots, etc. but apparently not with Kwin. Now, once we do fix the compressed buffer thing enabling direct scan-out, maybe we will need to add a third swapchain image anyway. That's assuming that Kwin's page flips will still be synchronized to the display refresh rate, which I believe is the case (correct me if I'm wrong). But is that really the solution users want? Sure, it would technically let the game run at an uncapped refresh rate, but as I understand it the main reason people want to run games that way is to minimize input latency, and they're willing to accept possible tearing as a trade-off (e.g. competitive gamers and whatnot). So would it maybe make more sense to have Kwin do tearing flips instead for direct scan-out applications? In *that* case I think 2 swapchain buffers on the driver side would still be fine, right? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 448917] NVIDIA/Wayland - Breeze Theme Has No Blur And Random Shapes Appear
https://bugs.kde.org/show_bug.cgi?id=448917 Erik Kurzinger changed: What|Removed |Added CC||ekurzin...@nvidia.com --- Comment #7 from Erik Kurzinger --- This should be fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/2358 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450914] Wayland, games on Nvidia are force vsynced
https://bugs.kde.org/show_bug.cgi?id=450914 --- Comment #8 from Erik Kurzinger --- Tried this with a debug NVIDIA driver, and it looks like the application is spending most of its time waiting for the PresentIdleNotify event from Xwayland. If vsync is disabled this should get delivered pretty much immediately, and as Samuel said, for windowed applications it does, but for full-screen applications for some reason we're only getting one every vblank interval. Probably the important different there is that Xwayland will use the "copy" path in xwayland-present.c for windowed applications but will use the "flip" path for full-screen / borderless applications. So like in the former case Xwayland will copy from the application's buffer to one of it's own buffers, and in the latter case it will pass the application's buffer directly to Kwin. As I understand it, with the copy path, the idle notification is sent immediately after the copy completes, but with the flip path it's only sent after the buffer has been released by Kwin. Is there possibly a difference between NVIDIA and Mesa that could cause Kwin to delay releasing these buffers? There is one known bug in our DRM driver where we don't report the correct timestamp for page flips (it will just be 0), not sure if that could be relevant. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 430207] Plasma desktop & SDDM aren't working properly with NVIDIA 455
https://bugs.kde.org/show_bug.cgi?id=430207 --- Comment #2 from Erik Kurzinger --- What Nate said. You can either send an email to linux-b...@nvidia.com or make a post here https://forums.developer.nvidia.com/c/gpu-unix-graphics/linux/ It would be helpful if you could run nvidia-bug-report.sh and attach the resulting file in your report. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428089] Restarting compositing breaks existing EGLStreams
https://bugs.kde.org/show_bug.cgi?id=428089 --- Comment #2 from Erik Kurzinger --- This is a tricky issue. Our client-side egl-wayland code really isn't set up to handle the compositor restarting. The client would need some way to become aware of this and send a new attach_eglstream_consumer request, and then re-attach the producer. Incidentally, we're currently working on driver-side support for passing buffers as dma-bufs, and once that's ready we could transition egl-wayland away from using EGLStreams. Then it should be possible to remove all of the EglStreamTexture stuff from kwin. Until then, though, maybe we could just defer applying any settings that require a compositor reset until the next login when using the EGLStreams backend? -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 427603] monitoring my NVIDIA does not show any info except temperature (missing output in nvidia-smi dmon)
https://bugs.kde.org/show_bug.cgi?id=427603 --- Comment #19 from Erik Kurzinger --- Ok, that is strange. It's kind of a separate issue to this ksysguard bug, though. Would you mind either sending an email to linux-b...@nvidia.com or starting a thread on https://forums.developer.nvidia.com/c/gpu-unix-graphics/linux/ ? We can follow up with you there. If you do so, it would help if you could run the nvidia-bug-report.sh script that we distribute with the driver and attach the file it generates. -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 427603] monitoring my NVIDIA does not show any info except temperature (missing output in nvidia-smi dmon)
https://bugs.kde.org/show_bug.cgi?id=427603 --- Comment #15 from Erik Kurzinger --- sorry, forgot to answer this... > and is there a way to have nvidia-smi report only the total framebuffer > memory size? no, I don't think so, sorry. You could always pipe its output through some other tool like awk, though. -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 427603] monitoring my NVIDIA does not show any info except temperature (missing output in nvidia-smi dmon)
https://bugs.kde.org/show_bug.cgi?id=427603 --- Comment #14 from Erik Kurzinger --- Bar1 is the portion of video memory that can be accessed by the CPU over PCIe. And yes, a graphical desktop environment would be expected to utilize GPU memory bandwidth, but only if you're actually interacting with it. If it's just sitting idle then it wouldn't be surprising that nvidia-smi reportes 0% mem utilization. Could you try running "nvidia-smi dmon" and, moving windows around or activating some desktop effects? This should cause the mem and SM values to increase, unless there really is a bug. -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 427603] monitoring my NVIDIA does not show any info except temperature (missing output in nvidia-smi dmon)
https://bugs.kde.org/show_bug.cgi?id=427603 --- Comment #11 from Erik Kurzinger --- The mem value reported by "nvidia-smi dmon" refers to memory bandwidth utilization. If the GPU isn't actively rendering anything, it's normal for it to be zero. It should increase if you run a game or something, though. Incidentally, SM refers to streaming multiprocessor, not shared memory. These are what actually run the shader code, and the value reported represents their utilization. Sorry, I know the nvidia-smi documentation could probably make this clearer. Together, the two numbers can be useful for identifying bottlenecks. If you want to know the video memory usage in the sense described here, you can run "nvidia-smi dmon -s m". It reports values for both framebuffer and bar1. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 424311] Severe Rendering Issues on Latest Nvidia Driver (450.57) (Arch)
https://bugs.kde.org/show_bug.cgi?id=424311 --- Comment #52 from Erik Kurzinger --- (In reply to br1ghtch1p from comment #51) > (In reply to Erik Kurzinger from comment #50) > > To update, there *was* a driver regression which seems to be responsible for > > the symptoms described here. See > > https://bugs.kde.org/show_bug.cgi?id=424592#c11 for a description of the > > issue. > > > > Unfortunately, I missed the deadline to get the fix into the 450.80 release > > yesterday. My apologies. However, it will be in the first official 455 > > release, which I believe is scheduled for Oct. 7. I've also back-ported it > > to the 450 branch, so it'll be in the *next* 450.xx release as well. > > Archlinux has already updated to version 455. Will there be a subsequent > update to realise the fix with those who are already in 455? The current 455.23 driver is technically a beta release. The next 455.xx driver will be the official release, and will contain the fix. Arch is usually pretty quick about updating their package, so I assume it will land in the repos soon after it's posted. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 424311] Severe Rendering Issues on Latest Nvidia Driver (450.57) (Arch)
https://bugs.kde.org/show_bug.cgi?id=424311 --- Comment #50 from Erik Kurzinger --- To update, there *was* a driver regression which seems to be responsible for the symptoms described here. See https://bugs.kde.org/show_bug.cgi?id=424592#c11 for a description of the issue. Unfortunately, I missed the deadline to get the fix into the 450.80 release yesterday. My apologies. However, it will be in the first official 455 release, which I believe is scheduled for Oct. 7. I've also back-ported it to the 450 branch, so it'll be in the *next* 450.xx release as well. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 424592] Sidebarview does not render after suspend
https://bugs.kde.org/show_bug.cgi?id=424592 --- Comment #12 from Erik Kurzinger --- Dang. Yes, this is indeed a regression in the 450 NVIDIA driver. Thank you for narrowing it down, David. I've identified the root cause and will try to get a fix included in the next minor version. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 424311] Severe Rendering Issues on Latest Nvidia Driver (450.57) (Arch)
https://bugs.kde.org/show_bug.cgi?id=424311 --- Comment #30 from Erik Kurzinger --- Are you certain this is a regression in the 450.57 driver? We've reproduced the issue internally at NVIDIA, but also observe similar corruption with a 440 series driver. It is possible the regression was actually caused by another package that just happened to be updated around the same time? One of KDE's components, Qt, or the kernel might be suspects. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 424592] Sidebarview does not render after suspend
https://bugs.kde.org/show_bug.cgi?id=424592 --- Comment #3 from Erik Kurzinger --- Possibly also related to https://bugs.kde.org/show_bug.cgi?id=424311 Out of curiosity, are you using a PRIME / hybrid graphics setup? I'm wondering if the issue is specific to such systems, as I've been using the 450.57 driver for a while and haven't noticed the issue personally (with dedicated graphics only). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353983] Turning off compositing breaks Plasma panel rendering
https://bugs.kde.org/show_bug.cgi?id=353983 --- Comment #179 from Erik Kurzinger --- (In reply to Sebastian Kuźlak from comment #177) > nvidia 450.51 beta claims to fix this issue. Yes, 450.51 should contain the fix. I would appreciate it if anyone who has been affected by this bug would be able to verify. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353983] Turning off compositing breaks Plasma panel rendering
https://bugs.kde.org/show_bug.cgi?id=353983 Erik Kurzinger changed: What|Removed |Added CC||ekurzin...@nvidia.com --- Comment #169 from Erik Kurzinger --- Took a look at this from the NVIDIA side and determined that it is a bug in our X driver. KWin / plasmashell aren't doing anything wrong. Should be able to get a fix out in an upcoming driver release. I'll include an entry in the change log mentioning the issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 --- Comment #96 from Erik Kurzinger --- (In reply to ssergio-ll from comment #93) > Qt Version: 5.12.3 Qt version 5.12.4 or later should contain the required patch. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 --- Comment #87 from Erik Kurzinger --- Did you apply the qtbase patch from the earlier comment on this bug? Or the one that was committed upstream? https://code.qt.io/cgit/qt/qtbase.git/commit/?id=0c1831178540462da31fd7a4b6d2e446bc84498b The patch was changed a bit during review, and I think the version ended up getting merged is more correct so I would recommend using that. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 Erik Kurzinger changed: What|Removed |Added Latest Commit|https://commits.kde.org/kwi |https://commits.kde.org/kwi |n/56cd5f5557fbec291a9d44f6f |n/0124b1ef191fcafe0d0f89287 |26fb76b5c34adae |be66b36833586e6 --- Comment #83 from Erik Kurzinger --- Git commit 0124b1ef191fcafe0d0f89287be66b36833586e6 by Erik Kurzinger. Committed on 19/06/2019 at 15:06. Pushed by ekurzinger into branch 'Plasma/5.16'. [platforms/X11] Disable VSync for QtQuick Windows Summary: QtQuick windows created by KWin currently use the default swap interval of 1, meaning buffer swaps will block until vblank. However, this results in a problematic interaction on hybrid graphics systems running the proprietary NVIDIA driver. VSync on such setups relies on a system called "PRIME synchronization", where the xf86-video-modesetting driver controlling the display will signal the NVIDIA driver when vblank has occurred. The issue is that it will only do so if there has been damage to the screen. So, when KWin creates a QtQuick window, compositing will stop waiting on the window to render, therefore no damage to the screen will occur. But this means that no vblank notifications will be delivered to the NVIDIA driver, so the glXSwapBuffers call by the QtQuick window will block perpetually. The end result is a freeze of the desktop. To get around this, we can simply disable vsync for QtQuick windows by setting the swap interval for the default QSurfaceFormat to 0. Since they are redirected, this shouldn't cause any tearing. FIXED-IN: 5.16.2 Test Plan: Using the proprietary NVIDIA driver on a hybrid graphics system, with PRIME synchronization enabled (see https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/), perform any action causing a QtQuick window to be created by KWin, for example, triggering the application switcher dialogue with alt + tab. Ensure the desktop does not temporarily freeze. Note, this required a Qt build that includes commit https://code.qt.io/cgit/qt/qtbase.git/commit/?id=0c1831178540462da31fd7a4b6d2e446bc84498b resolving a bug that prevented the changing the swap interval. Reviewers: #kwin, davidedmundson, zzag Reviewed By: #kwin, davidedmundson, zzag Subscribers: zzag, romangg, alexeymin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21808 M +6-0main_x11.cpp https://commits.kde.org/kwin/0124b1ef191fcafe0d0f89287be66b36833586e6 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 Erik Kurzinger changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://commits.kde.org/kwi ||n/56cd5f5557fbec291a9d44f6f ||26fb76b5c34adae Version Fixed In||5.16.2 Status|CONFIRMED |RESOLVED --- Comment #82 from Erik Kurzinger --- Git commit 56cd5f5557fbec291a9d44f6f26fb76b5c34adae by Erik Kurzinger. Committed on 19/06/2019 at 14:56. Pushed by ekurzinger into branch 'master'. [platforms/X11] Disable VSync for QtQuick Windows Summary: QtQuick windows created by KWin currently use the default swap interval of 1, meaning buffer swaps will block until vblank. However, this results in a problematic interaction on hybrid graphics systems running the proprietary NVIDIA driver. VSync on such setups relies on a system called "PRIME synchronization", where the xf86-video-modesetting driver controlling the display will signal the NVIDIA driver when vblank has occurred. The issue is that it will only do so if there has been damage to the screen. So, when KWin creates a QtQuick window, compositing will stop waiting on the window to render, therefore no damage to the screen will occur. But this means that no vblank notifications will be delivered to the NVIDIA driver, so the glXSwapBuffers call by the QtQuick window will block perpetually. The end result is a freeze of the desktop. To get around this, we can simply disable vsync for QtQuick windows by setting the swap interval for the default QSurfaceFormat to 0. Since they are redirected, this shouldn't cause any tearing. FIXED-IN: 5.16.2 Test Plan: Using the proprietary NVIDIA driver on a hybrid graphics system, with PRIME synchronization enabled (see https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/), perform any action causing a QtQuick window to be created by KWin, for example, triggering the application switcher dialogue with alt + tab. Ensure the desktop does not temporarily freeze. Note, this required a Qt build that includes commit https://code.qt.io/cgit/qt/qtbase.git/commit/?id=0c1831178540462da31fd7a4b6d2e446bc84498b resolving a bug that prevented the changing the swap interval. Reviewers: #kwin, davidedmundson, zzag Reviewed By: #kwin, davidedmundson, zzag Subscribers: zzag, romangg, alexeymin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21808 M +6-0main_x11.cpp https://commits.kde.org/kwin/56cd5f5557fbec291a9d44f6f26fb76b5c34adae -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 --- Comment #79 from Erik Kurzinger --- https://codereview.qt-project.org/c/qt/qtbase/+/264563 It was suggested to just remove the m_swapInterval variable entirely instead of resetting it in doneCurrent, but it should have the same effect as far as this bug is concerned. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 --- Comment #76 from Erik Kurzinger --- The Qt patch has been submitted for review, sorry about the delay. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 407966] [NVIDIA][Wayland] Krunner does not show any result after writing any text
https://bugs.kde.org/show_bug.cgi?id=407966 --- Comment #1 from Erik Kurzinger --- Sorry for taking a while to look into this, however it would seem krunner's QSGRenderThread is getting stuck in eglSwapBuffers waiting for a wl_surface::frame event. I think this is a similar issue to what I tried to address in https://phabricator.kde.org/D18307. It looks like if Compositor::performCompositing detects that no windows have been damaged, it will return early without servicing any frame events. Just trying to confirm this and figure out the best way to get around the issue. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 407968] [NVIDIA][Wayland] systemsettings opens but no UI is loaded
https://bugs.kde.org/show_bug.cgi?id=407968 --- Comment #2 from Erik Kurzinger --- If that's the case, I suspect https://github.com/NVIDIA/egl-wayland/commit/547055cb58690515077bd9f02b1325ed677650c1 might have been the fix. With that change we now correctly report whether EGL images are Y-inverted or not. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 --- Comment #48 from Erik Kurzinger --- (In reply to Guilherme Almeida from comment #47) > (In reply to Luca Carlon from comment #22) > > Hello, I'm also affected by this issue. It is so severe that the system was > > hardly usable. I just noticed one thing: I suspect the issue appears for me > > only when drm is enabled with nvidia-drm.modeset=1. By default this was not > > set in Kubuntu 18.10 and 19.04 (may explain why Peter Eszlari could not > > reproduce?). Unfortunately drm is the only way I found to prevent horizontal > > tearing. > > No idea if this info is already known or of any help to you. > > I can confirm that, Luca. Using PRIME on Manjaro 18.0.4, I changed > /etc/modprobe.d/nvidia-drm.conf, setting like this options nvidia_drm > modeset=0 and the the frezze has stoped. I haven't noticed tearing so far, > but if happens I will edit this reply. Note that the reason this resolves the issue is that is disables PRIME synchronization entirely (see https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/ for details). So tearing would be expected, since this is how the NVIDIA driver is made aware of each vblank by the Intel driver. Only disabling vsync for the QtQuick pop-ups would definitely be a preferable solution, I think. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 --- Comment #41 from Erik Kurzinger --- It might be quicker for you to submit the Qt patch if you don't mind. We need to go through some bureaucracy at NVIDIA to get approval before contributing to open source projects which can delay things a bit. It should be possible to detect a PRIME setup using RandR, specifically the XRRGetProviderResources and XRRGetProviderInfo calls. If we're using the NVIDIA driver for OpenGL, but the NVIDIA-0 provider doesn't advertise the "sink output" capability, that should be sufficient to infer a PRIME system. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 --- Comment #38 from Erik Kurzinger --- Should also note that the above needs to be applied in addition to David's patch to KWin itself -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 --- Comment #37 from Erik Kurzinger --- > Do you mean "the first time the switcher is displayed after kwin process > started"? Yes, that's what I meant. Maybe also after restarting compositing. This patch to qtbase seems to fix things for me if you want to give it a shot. diff --git a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp index 4adf662152..434ea60bfb 100644 --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() else glXMakeCurrent(m_display, 0, 0); m_isPBufferCurrent = false; +m_swapInterval = -1; } void QGLXContext::swapBuffers(QPlatformSurface *surface) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4+ hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 --- Comment #34 from Erik Kurzinger --- Setting the swap interval to 0 *should* resolve the issue, and indeed, on my system the first time the window switcher is displayed it never hangs. However, subsequent times it still can. Luca, does this agree with your observations? The issue, I think, is that QtQuick only calls glXSwapIntervalEXT the first time its context is made current. See QGLXContext::makeCurrent in src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp in the core Qt code. It checks if the surface's swap interval is different than it's internal m_swapInterval, and only calls the GLX function if so. The issue is that the swap interval is associated with a particular drawable, not a context, and QtQuick creates a new drawable each time the switcher is displayed. However, since the swap interval hasn't changed since the last time it's context was made current, it skips the glXSwapIntervalEXT call when it really shouldn't. It should probably be resetting m_swapInterval in QGLXContext::doneCurrent or something. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406180] KWin 5.15.4 hang regression on Nvidia Optimus
https://bugs.kde.org/show_bug.cgi?id=406180 Erik Kurzinger changed: What|Removed |Added CC||ekurzin...@nvidia.com -- You are receiving this mail because: You are watching all bug changes.
