| Summary: | Partial image freeze when changing display configuration | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Max Sydorenko <maxim.stargazer> |
| Component: | xrandr | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | major | CC: | maxim.stargazer |
| Priority: | NOR | Flags: | thomas.luebking:
Intel+
|
| Version First Reported In: | 5.5.1 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
kwin supportInfo from OP
Xorg.log |
||
|
Description
Max Sydorenko
2015-12-21 18:04:45 UTC
Related to this? (read entire thread and notably stackexchange question) http://lists.x.org/archives/xorg/2015-December/057824.html In doubt about intel driver version, please attach /var/log/Xorg.0.log (also to see the acceleration method) Also please be aware that Arch just changed to libc6, so if you've *any* X11 or kernel modules from aur (or elsewhere) that might cause trouble. Created attachment 96246 [details]
kwin supportInfo from OP
On a sidenote, please attach all bug information and don't use pastebin.
Created attachment 96248 [details]
Xorg.log
I tested the last (patched) version of xf86-video-intel (attached log relates to it), which supposed to solve mentioned supposedly related problem. Still able to reproduce my original problem. Thanks for testing nevertheless.
Does this
> image of window open on the laptop display is frozen
mean the VGA section works just fine?
Does suspending/resuming the compositor (SHIFT+Alt+F12) resolve the frozen display as well?
Does the EGL or xrender backend ("kcmshell5 kwincompositing") expose the same behavior?
(I assume xrender won't)
Does this have any impact:
KWIN_USE_BUFFER_AGE=0 KWIN_EXPLICIT_SYNC=0 KWIN_USE_INTEL_SWAP_EVENT=0 KWIN_PERSISTENT_VBO=0 kwin_x11 --replace &
Is the enabled TearFree option relevant? (should be set in some /etc/X11/xorg.conf.d/*intel* snippet), ie. does disabling it change something?
> Does this > > image of window open on the laptop display is frozen > mean the VGA section works just fine? Yes, it does. > Does suspending/resuming the compositor (SHIFT+Alt+F12) resolve the frozen > display as well? Yes. > Does the EGL or xrender backend ("kcmshell5 kwincompositing") expose the > same behavior? > (I assume xrender won't) Both are free of this problem. > Does this have any impact: > KWIN_USE_BUFFER_AGE=0 KWIN_EXPLICIT_SYNC=0 KWIN_USE_INTEL_SWAP_EVENT=0 > KWIN_PERSISTENT_VBO=0 kwin_x11 --replace & No, same behavior. Removing TearFree option from the xorg.conf.d/ files completely resolved original problem. Thank you for helping pinpointing the cause. What is the current status of this option, btw? Is it considered obsolete and replaced by Tearing Prevention menu in Compositor Settings? Unrelated: Removing TearFree option changed apearence of xembed-sni-proxi icon (Dropbox, to be precise). Now it looks like a black square with a dropbox icon in it, before it blended nicely with a default Breeze light theme. Is it known behaviour? Can I disable xembed-sni-proxi all together? Sorry for my last digression. It is better to ask David Edmundson about those things, I somehow mixed him in my mind with Thomas. Thank you once again. The TearFree setting in the Xorg intel driver is not (really) related to GL swap control in clients (like the KWin compositor scene) Afaics, you should have buffer_age support which means kwin will swap, thus flip, so TearFree should not be required, BUT: you'll likely get tearing (now) when playing videos etc. uncomposited. Apparently the TearFree option is buggy reg. randr events, I suggest to file a bug on https://bugs.freedesktop.org - I cannot recall any relevant changes in KWin itr., notably none that would cover XRender as well and on top of all freeze the topleft (old root area, this could not be explained by "we forget to resize the overlay window") screen. Was the "good" screen btw. fully composited (with shadows, translucency, fading in windows etc.) or just "visible at least"? > Was the "good" screen btw. fully composited (with shadows, translucency,
> fading in windows etc.) or just "visible at least"?
Yes, it was fully composited, even part of the Present All Windows animation was visible on it (most of the windows thumbnails where "presented" on the main display, but not visible because of the image freeze). And I was able to drag blindfolded "frozen" application from the main display to attached monitor, where it was functional, while "screenshot" of this app was still presented on main display.
|