Summary: | Plasma widget rendering is corrupted when using nouveau and virtualbox | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | eric.erfanian |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | major | ||
Priority: | NOR | ||
Version: | 4.10.2 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Artifacts 1
Artifacts 2 xprop before xprop after glxinfo - Nvidia |
Description
eric.erfanian
2013-04-24 12:49:01 UTC
Created attachment 79411 [details]
Artifacts 1
Created attachment 79412 [details]
Artifacts 2
> Qt Graphics System: native
Try "raster", also please attach the output of "xprop -root", ideally before AND after starting VB, thus causing the issue.
Tried with raster/native options no change. Attaching before and after. Created attachment 79414 [details]
xprop before
Created attachment 79415 [details]
xprop after
I assume it does not go away if you simply toggle the compositor (Shift+Alt+F12, twice) but what if you suspend the compositor, then call xprop -root -remove RGB_DEFAULT_MAP then resume the compositor? it will essentially be bug #262064 (found it ;-) @Martin Should we do sth, like monitor that property and whenever set on the root, issue a warning, explanation, "how to fix it" and suspend the compositor as long as it's there? (No, i don't like that, but it makes KWin appear broken and no user can ever even remotely figure "why") *** This bug has been marked as a duplicate of bug 262064 *** well we could monitor for it and remove it. imo too aggressive - we don't know who set it why (could have been the user, despite apparently unreasonable it's perfectly legal) also every client started after or at least every window mapped after will remain affected (getting us a bugreport what i want to avoid ;-) and we would "fix" a bug by another one. We could simply send a notification like when the compositor was suspended externally. It does not go away when toggling the compositer, and it does not go away when suspending, executing the command, then resuming. (In reply to comment #7) > I assume it does not go away if you simply toggle the compositor > (Shift+Alt+F12, twice) but what if you suspend the compositor, then call > > xprop -root -remove RGB_DEFAULT_MAP > > then resume the compositor? restart plasma (or any application that belongs to the "broken" window) after withdrawing the property. Also ensure virtualbox does not just set it back again. (It's not related to kwin, the property breaks the client which then hands out broken pixmaps, my bad - sorry) As long as that property is there, no 32bit stuff will work (as long as the application supports custom color tables - as do all Qt ones) reasonably. It simply does not belong there, virtualbox wants to set it on it's own window, not the root. This also has nothing to do with nouveau. Thanks for the info. Do you know why this didn't happen with the intel or proprietary nvidia drivers? I'm not sure what you mean by restart plasma. Should I log out? I also tried variations of: 1) disable compositor 2) remove RGB_DEFAULT_MAP 3) kwin --replace 4) enable compositor. Still had artifacts. (In reply to comment #14) > I'm not sure what you mean by restart plasma. Supposing the defective item belongs to the desktop (as the popup in the screenshot) kquitapp plasma-desktop; sleep 3; plasma-desktop The other screenshot shows krunner, so: kquitapp krunner; sleep 3; krunner > Still had artifacts. The bug is not in kwin, restarting it won't do (rather worse) (In reply to comment #13) > Thanks for the info. Do you know why this didn't happen with the intel or > proprietary nvidia drivers? No idea, same virtualbox version? Is there the *exact* same (in all fields) property? (In reply to comment #15) > (In reply to comment #14) > > I'm not sure what you mean by restart plasma. > Supposing the defective item belongs to the desktop (as the popup in the > screenshot) > > kquitapp plasma-desktop; sleep 3; plasma-desktop > > The other screenshot shows krunner, so: > > kquitapp krunner; sleep 3; krunner > > > Still had artifacts. > The bug is not in kwin, restarting it won't do (rather worse) > > (In reply to comment #13) > > Thanks for the info. Do you know why this didn't happen with the intel or > > proprietary nvidia drivers? > > No idea, same virtualbox version? > Is there the *exact* same (in all fields) property? I haven't tried restarting plasma because I switched back to the proprietary nvidia drivers. I can confirm the bug no longer appears, same program versions. do you happen to have a "glxinfo" output of nouveau installation around (so one could inspect the visuals and compare them to current nvidia) notice that the property nevertheless does not belong there and can cause "weird" results nevertheless (see dupes where the visual chosen by cairo-dock broke smplayer) (In reply to comment #17) > do you happen to have a "glxinfo" output of nouveau installation around (so > one could inspect the visuals and compare them to current nvidia) > Unfortunately not. I'll attach the nvidia glxinfo now and then when I switch back to nouveau I'll update this ticket. > notice that the property nevertheless does not belong there and can cause > "weird" results nevertheless (see dupes where the visual chosen by > cairo-dock broke smplayer) Created attachment 79492 [details]
glxinfo - Nvidia
|