| Summary: | Crashes/visual curruption/lost windows on HIGH-dpi (4k) scaled multiscreen | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Vincenzo Di Massa <hawk.it> |
| Component: | xrandr | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | ||
| Priority: | NOR | ||
| Version First Reported In: | 5.5.4 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
xorg patch I'mk using to fix mouse cursor problems
script to setup an external (non HIGH DPI monitor) using xrandr qdbus org.kde.KWin /KWin supportInformation xorg log KWin hangs |
||
|
Description
Vincenzo Di Massa
2016-04-15 08:58:32 UTC
(In reply to Vincenzo Di Massa from comment #0) > When using the fixDisplay.sh script What fixDisplay.sh script? > 1) end up with an Xorg crash (problem1) Xorg bug, check /var/log/Xorg.*.log for possible backtraces. > 2) end up with some of the open windows disappearing (not on any > display/desktop/activity), but the processes are still running and it is > still possible to list the x window ID Qt5 is completely broken on randr events, see bug #341497 > While kwin is working I get reversible and temporary visual corruptions > (expecially in konsole) while scrolling. What makes you believe this is a bug in KWin? Does it happen with suspended compositor as well (SHIFT+Alt+F12) Please attach the output of "qdbus org.kde.KWin /KWin supportInformation" and /var/log/Xorg.0.log ---- nb. that multiscreen is completely dysfunctional and that will remain at least until Qt5.6 & Plasma 5.7 Created attachment 98404 [details] xorg patch I'mk using to fix mouse cursor problems https://bugs.freedesktop.org/attachment.cgi?id=94929 https://bugs.freedesktop.org/show_bug.cgi?id=39949 Created attachment 98405 [details]
script to setup an external (non HIGH DPI monitor) using xrandr
The script scales the resolution of my laptop monitor down to the resolution of the attached monitor using xrandr
Created attachment 98406 [details]
qdbus org.kde.KWin /KWin supportInformation
Created attachment 98407 [details]
xorg log
(In reply to Vincenzo Di Massa from comment #5) > Created attachment 98407 [details] > xorg log that doesn't contain an xorg crash. You have to look into the old log after a crash. (In reply to Thomas Lübking from comment #1) > (In reply to Vincenzo Di Massa from comment #0) > What fixDisplay.sh script? Really fast answer, I have now made it an attachment. > > 1) end up with an Xorg crash (problem1) > Xorg bug, check /var/log/Xorg.*.log for possible backtraces. I'll attach next crash log. > > 2) end up with some of the open windows disappearing (not on any > > display/desktop/activity), but the processes are still running and it is > > still possible to list the x window ID > > Qt5 is completely broken on randr events, see bug #341497 I suspected this. Anyways it is working "sort of ok" except that in my setup (when none or all of the displays are HIGH dpi, and thus I'm not scaling. > > While kwin is working I get reversible and temporary visual corruptions > > (expecially in konsole) while scrolling. > > What makes you believe this is a bug in KWin? Kwin often crashes, its output spawns (cryptic for me) errors. (see attached file). I have windows listed by X that kwin does not render (I'm not sure I get how compositing works BTW). > Does it happen with suspended compositor as well (SHIFT+Alt+F12) > Please attach the output of "qdbus org.kde.KWin /KWin supportInformation" > and /var/log/Xorg.0.log Done, I'll try disablin the compositor and report back. > ---- > nb. that multiscreen is completely dysfunctional and that will remain at > least until Qt5.6 & Plasma 5.7 Great news! I'm really looking forward. Do you reccomend any workaround to make kwin/kde apps play nicely with my monitors in the meantime? Whooops, I realize just now that in the description I did not tell that that kwin also crashes may times a day, but ONLY in this setup. BTW you, and the kde people, rock! for kwin crashes, please attach the developer informations from the crash dialog (backtrace) (reg. xorg.0.log, i wanted to check for egl/dri3 - xorg.1.log will contain x11 backtraces only directly after an xorg server crash) I tried to get such logs, but the system becomes unresponsive in such cases. I have to terminate kwin from a vt like this. killall -9 kwin_x11 && sleep 1 ; kwin_x11 --replace & chvt 7 I realze I should s/crashes/hungs/g on my prevoius sentences. notice that sending sigterm (or just calling kwin --replace ) does not work, thus I use sigkill. I could run kwin into a debugger to backtrace where it crashes, would this help? You may run into bug #353428 (is the kwin process stopped?) And yes, a backtrace would be tremendously helpful, TIA =) Created attachment 98444 [details]
KWin hangs
Here Kwin hangs, it does not actually crash. It just gets unresponsive and clicking on anything becomes impossible even if the mouse can still be moved around. I think this happens more often than crashes. I will wait for a crash log to happen in the meantime I share this backtrace (btw I posted it yesterday on the wrong bug).
Killing kwin and restaring it does recover the situation momentarily.
I suspect I have more than one problem
This is not bug #353428 - that bug happens when kwin segfaults and fails to recover because the process stopped by drkonqui still has the WM selection on the X11 server (and can't release it since it's stopped) The backtraces you posted look like a race condition between the QtScript and QXcbEventReader thread (at least both wait for a mutex) Do you use some XIM (fcitx etc.)? I'm not sure what XIM is, I know it is used to extend input methods capabilities in X (if I got it correctly) but I don't know how to configure it and check if I'm using it. I guess I'm not using it since I installed an english version of kubuntu, but I'll investigate (and learn what XIM really is, btw :-) ). It's typilcally used by Asians and Slavs and other people using the wrong alphabet - ie. not the one your ancestors stole from the Greek and propagated to the rest of the (European) world ;-) Just asked because there's a bug about a hanging QXcbEventReader which seems tied to XIM. I'd try w/o the Xorg patch. While I don't really know what it changes, it does seem to introduce randr queries during input clamping (what will typically happen during input events) - it certainly looks related (but there's oc. not guarantee that this is the problem) Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |