| Summary: | Secondary user actions popup remains visible | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Viorel-Cătălin Răpițeanu <rapiteanu.catalin> |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kde.org, linux, mwinthrop, rapiteanu.catalin |
| Priority: | NOR | ||
| Version First Reported In: | 5.5.95 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Kwin qdbus log from the machine using bumblebee (intel + nvidia)
Kwin qdbus log from a machine using nouveau (without acceleration) The computer specification used in the video. |
||
|
Description
Viorel-Cătălin Răpițeanu
2016-03-18 21:03:36 UTC
> unrecoverable
SHIFT+Alt+F12
Just to be sure - the popup remainder *is* a visual artifact, you cannot interact with it anymore, it doesn't block clicks and enforcing a repaint of there area (by moving a window around) clears the stage?
Please attach the output of
qdbus org.kde.KWin /KWin supportInformation
> SHIFT+Alt+F12 Disabling the compositor will recover the system state. > Just to be sure - the popup remainder *is* a visual artifact, you cannot interact with it anymore, it doesn't block clicks and enforcing a repaint of there area (by moving a window around) clears the stage? It is. The surfaces behind it correctly receive input events. Also, the popup stays on top of the surface when I'm forcing a repaint. I'll add the log in a moment. Created attachment 97962 [details]
Kwin qdbus log from the machine using bumblebee (intel + nvidia)
Created attachment 97963 [details]
Kwin qdbus log from a machine using nouveau (without acceleration)
On this machine the display will not start to glitch if the steps are repeated.
Ftr:
> Qt compile version: 5.6.0
nouveau is on the xrender compositor, the other system Sandybridge on GLX/3
=> "kcmshell5 kwincompositing", switch to xrender - does the issue remain?
In case not, please return to opengl, close the dialog and run "kcmshell5 kwineffects". Disable "blur" & "contrast" effects (just a wild guess) and see whether it still remains.
If yes, for a final test also disable the "fade" effect and finally report your findings.
> system Sandybridge on GLX/3 => "kcmshell5 kwincompositing", switch to xrender - does the issue remain? The popup remainder visual artifact is remaining, but the display glitch doesn't seem to happen anymore. > In case not, please return to opengl, close the dialog and run "kcmshell5 kwineffects". Disable "blur" & "contrast" effects (just a wild guess) and see whether it still remains. Disabling blur and contrast hasn't made the display glitch go away. > If yes, for a final test also disable the "fade" effect and finally report your findings. Same as with blur and contrast, disabling fade hasn't influenced the display glitch. The "display glitch" is probably a red herring (you may be running out of texture memory at some point) On the bottom line, the unmap_notify event for the second popup is missed (so the compositor believes it's still there) - I sense relation to bug #351112 (and Qt 5.6) Does it also happen when invoking the popup with Alt+F3? > Does it also happen when invoking the popup with Alt+F3?
I've tried this multiple times, and isn't.
The second popup remains drawn only when the first popup is invoked by right clicking the title bar.
I fail to reproduce, but I'm also on Qt 5.6 Created attachment 98057 [details] The computer specification used in the video. I can still reproduce it on Qt 5.6. You must hit a certain timing to trigger this problem, as it can be seen in this video: https://drive.google.com/file/d/0B84qTYLQoOLNZkZPeXUwc25vblU/view?usp=sharing The specification of the machine used in the video is attached to this message. The HW likely doesn't matter (at least not reg. the core issue of the pending menu) Try to disable the translucency effect - while it doesn't see invoked, it might still be prone to falsely keep the popup alive. Can you compile and run patches to kwin? (In reply to Thomas Lübking from comment #11) > The HW likely doesn't matter (at least not reg. the core issue of the > pending menu) > Try to disable the translucency effect - while it doesn't see invoked, it > might still be prone to falsely keep the popup alive. > > Can you compile and run patches to kwin? At the present moment, I can't. I'll try to set a KDE dev setup later this week if nobody is able to test it until then. Can confirm this. Problem is that it happens randomly and thus is hard to track. I've often seen this happening when using the "Move to Screen" menu. The glitch does also go away if the same menu is used again (maybe the bug reporter can confirm that?). (In reply to Bernd Steinhauser from comment #13) > Can confirm this. Problem is that it happens randomly and thus is hard to > track. > I've often seen this happening when using the "Move to Screen" menu. > > The glitch does also go away if the same menu is used again (maybe the bug > reporter can confirm that?). I can confirm that this happens often when you are trying to move an application to a different screen/workspace. To reproduce this more easily, you should try to click outside of the popups as soon as the second popup is being displayed. I succeeded to reproduce with two input devices: 1. open context menu 2. open sub menu 3. hover an action with the mouse 4. Use touch screen to close The sub-menu stays as a zombie, but can be brought back to life by opening it again. *** Bug 372149 has been marked as a duplicate of this bug. *** This issue doesn't seem to reproduce on my latest setup that's using the proprietary nvidia driver (not even when I'm using 2 different input sources). Since a lot changed during these 3 years, this scenario should be rechecked on a system with nouveau/intel drivers as well. User reports that he cannot reproduce the problem anymore |