[solved] kwin_x11 / Plasma / Compositing freezes

whoops · 2016-08-02 09:35:32

Hi!

A few weeks ago, I was affected by several nvidia / kde / xorg / kernel issues at once after updating. Some of those problems were related, some not. I worked around the ones that needed workarounds (had to switch to LTE kernel for a while, had to delete part of my KDE configuration and the saved session, remove the vsync fix from xorg conf because nvidia broke it... and more... over the course of 1-2 weeks), I think the ones that needed fixing got fixed upstream... And I totally lost track of what's going on.

Now that everything should be back to normal (should all be fixed / fixable by now, right?), the problem that I still have are occasional freezes of kwin. Probably compositing related (happens mostly but not exclusively when I switch desktops). Screen freezes, kwin_x11 takes up 100% of one cpu core and becomes "unkillable" (except with -9). Using kwin --replace results in a second instance being started. "Xorg level" Keyboard does not work any more (I tried an xbindkey script to kill & restart kwin - doesn't work), but TTY switching / SysR-Stuff still does. Starting a new kwin from TTY makes KDE work again. There are NO log / journal messages related to this at all (I even re-activated kernel + KDE debug messages. Nothing. )

Those kind of freezes never happened before I got hit by that confusing multi-bug mess.

Does / did anyone have the same "leftover" problem?
I already went over the threads of the various other (fixed) issues several times and I was not able to find what I missed / where I might have gone wrong.
Any ideas?

Last edited by whoops (2016-12-16 15:35:08)

V1del · 2016-08-02 10:54:39

Can't confirm, post ALL of your configuration that you currently have active that might have a relation (Xorg.conf files, environment exports from /etc/profile(.d), /etc/environment and friends) also post your hardware config

lspci -k 
pacman -Qs nvidia
dmesg

come to mind. Saying you went over all the threads without naming any of them, nor what changes you actually did end up using is pretty useless in terms of getting this resolved, posting the journal might still be helpful because maybe there's some context you are missing.

pb · 2016-08-02 11:38:14

And another one:

/usr/lib/qt/bin/qdbus org.kde.KWin /KWin supportInformation

Have you tested Plasma on clean configuration or on new (testing) user? Yours problem occour, too?

Last edited by pb (2016-08-02 11:38:27)

whoops · 2016-08-02 12:19:15

Sorry, should have mentioned: I didn't post any configs etc, because I "tested" (restored backup from time when the freezes didn't happen yet + tried archlinux default + deleting all together where applicable) the potentially relevant ones - well, the ones I could think of - over the course of the last week.
- I'm using nvidia 367.35 (with a GeForce GTX 970) at the moment and linux 4.6.4
- There is nothing even remotely related in the journal. I compared it to logs from 2 months ago, before the problem occurred. Same with xorg logs, dmesg.
- Don't have any relevant environment variables
- I have deleted my xorg configuration, used nvidia-xconfig and deleted it again after that didn't help.
- Also reset my nvidia-settings.

What I DID find just now was:

options nvidia NVreg_RegisterForACPIEvents=1 NVreg_EnableMSI=1

... in my modprobe.d, so thanks for reminding me! Probably not related, but I can't remember why I added that (a year ago, according to ls) so I probably don't need it any more. I'll remove it after I post this and reboot / test if it changes anything. *sigh* I should really add comments to such things to remind myself why I added them in the first place... maybe I didn't know why at that time and was just experimenting.

Saying you went over all the threads without naming any of them, nor what changes you actually did end up using is pretty useless in terms of getting this resolved

Well, if anyone else was hit by even half of that same update breakage that started for me ~1 month ago, that person would definitely remember. I was hoping that maybe I just missed one important / well known workaround or another that many kde / nvidia users might or might not have applied within the last few weeks. And making a list of the threads in which I couldn't find a solution for my problems didn't seem like a good idea at the time

And another one:

/usr/lib/qt/bin/qdbus org.kde.KWin /KWin supportInformation
KWin Support Information:
The following information should be used when requesting support on e.g. http://forum.kde.org.
It provides information about the currently running instance, which options are used,
what OpenGL driver and which effects are running.
Please post the information provided underneath this introductory text to a paste bin service
like http://paste.kde.org instead of pasting into support threads.

==========================

Version
=======
KWin version: 5.7.2
Qt Version: 5.7.0
Qt compile version: 5.7.0
XCB compile version: 1.12

Operation Mode: X11 only

Build Options
=============
KWIN_BUILD_DECORATIONS: yes
KWIN_BUILD_TABBOX: yes
KWIN_BUILD_ACTIVITIES: yes
HAVE_INPUT: yes
HAVE_DRM: yes
HAVE_GBM: yes
HAVE_X11_XCB: yes
HAVE_EPOXY_GLX: yes
HAVE_WAYLAND_EGL: yes

X11
===
Vendor: The X.Org Foundation
Vendor Release: 11804000
Protocol Version/Revision: 11/0
SHAPE: yes; Version: 0x11
RANDR: yes; Version: 0x14
DAMAGE: yes; Version: 0x11
Composite: yes; Version: 0x4
RENDER: yes; Version: 0xb
XFIXES: yes; Version: 0x50
SYNC: yes; Version: 0x31
GLX: yes; Version: 0x0

Decoration
==========
Plugin: org.kde.breeze
Theme: 
Blur: 0
onAllDesktopsAvailable: true
alphaChannelSupported: true
closeOnDoubleClickOnMenu: false
decorationButtonsLeft: 0, 2
decorationButtonsRight: 6, 3, 4, 5
borderSize: 3
gridUnit: 8
font: Diavlo,10,-1,5,50,0,0,0,0,0
smallSpacing: 2
largeSpacing: 8

Options
=======
focusPolicy: 0
nextFocusPrefersMouse: false
clickRaise: true
autoRaise: false
autoRaiseInterval: 0
delayFocusInterval: 0
shadeHover: false
shadeHoverInterval: 250
separateScreenFocus: false
placement: 4
focusPolicyIsReasonable: true
borderSnapZone: 10
windowSnapZone: 10
centerSnapZone: 0
snapOnlyWhenOverlapping: false
rollOverDesktops: true
focusStealingPreventionLevel: 1
legacyFullscreenSupport: false
operationTitlebarDblClick: 5000
operationMaxButtonLeftClick: 5000
operationMaxButtonMiddleClick: 5015
operationMaxButtonRightClick: 5014
commandActiveTitlebar1: 0
commandActiveTitlebar2: 30
commandActiveTitlebar3: 2
commandInactiveTitlebar1: 4
commandInactiveTitlebar2: 30
commandInactiveTitlebar3: 2
commandWindow1: 7
commandWindow2: 8
commandWindow3: 8
commandWindowWheel: 31
commandAll1: 10
commandAll2: 3
commandAll3: 14
keyCmdAllModKey: 16777251
showGeometryTip: false
condensedTitle: false
electricBorderMaximize: true
electricBorderTiling: true
electricBorderCornerRatio: 0.25
borderlessMaximizedWindows: false
killPingTimeout: 5000
hideUtilityWindowsForInactive: true
inactiveTabsSkipTaskbar: false
autogroupSimilarWindows: false
autogroupInForeground: true
compositingMode: 1
useCompositing: true
compositingInitialized: true
hiddenPreviews: 1
unredirectFullscreen: false
glSmoothScale: 2
colorCorrected: false
xrenderSmoothScale: false
maxFpsInterval: 16666666
refreshRate: 0
vBlankTime: 6000000
glStrictBinding: false
glStrictBindingFollowsDriver: true
glCoreProfile: false
glPreferBufferSwap: 0
glPlatformInterface: 1

Screen Edges
============
desktopSwitching: false
desktopSwitchingMovingClients: false
cursorPushBackDistance: 1x1
timeThreshold: 150
reActivateThreshold: 350
actionTopLeft: 0
actionTop: 0
actionTopRight: 0
actionRight: 0
actionBottomRight: 0
actionBottom: 0
actionBottomLeft: 0
actionLeft: 0

Screens
=======
Multi-Head: no
Active screen follows mouse:  no
Number of Screens: 1

Screen 0:
---------
Name: DVI-I-1
Geometry: 0,0,1920x1080
Refresh Rate: 60


Compositing
===========
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 970/PCIe/SSE2
OpenGL version string: 4.5.0 NVIDIA 367.35
OpenGL platform interface: GLX
OpenGL shading language version string: 4.50 NVIDIA
Driver: NVIDIA
Driver version: 367.35
GPU class: Unknown
OpenGL version: 4.5
GLSL version: 4.50
X server version: 1.18.4
Linux kernel version: 4.6.4
Direct rendering: Requires strict binding: no
GLSL shaders:  yes
Texture NPOT support:  yes
Virtual Machine:  no
OpenGL 2 Shaders are used
Painting blocks for vertical retrace:  no

Loaded Effects:
---------------
zoom
slidingpopups
kwin4_effect_login
slide
screenshot
kwin4_effect_translucency
minimizeanimation
kwin4_effect_windowaperture
desktopgrid
kwin4_effect_morphingpopups
kwin4_effect_fade
kwin4_effect_maximize
kwin4_effect_dialogparent
presentwindows
highlightwindow
blur
contrast
logout
startupfeedback
screenedge
kscreen

Currently Active Effects:
-------------------------
blur
contrast

Effect Settings:
----------------
zoom:
zoomFactor: 1.2
mousePointer: 0
mouseTracking: 0
enableFocusTracking: false
followFocus: true
focusDelay: 350
moveFactor: 20
targetZoom: 1

slidingpopups:
fadeInTime: 150
fadeOutTime: 250

kwin4_effect_login:

slide:

screenshot:

kwin4_effect_translucency:

minimizeanimation:

kwin4_effect_windowaperture:

desktopgrid:
zoomDuration: 300
border: 10
desktopNameAlignment: 0
layoutMode: 0
customLayoutRows: 2
usePresentWindows: true

kwin4_effect_morphingpopups:

kwin4_effect_fade:

kwin4_effect_maximize:

kwin4_effect_dialogparent:

presentwindows:
layoutMode: 0
showCaptions: true
showIcons: true
doNotCloseWindows: false
ignoreMinimized: false
accuracy: 20
fillGaps: true
fadeDuration: 150
showPanel: false
leftButtonWindow: 1
rightButtonWindow: 2
middleButtonWindow: 0
leftButtonDesktop: 2
middleButtonDesktop: 0
rightButtonDesktop: 0

highlightwindow:

blur:
blurRadius: 12
cacheTexture: true

contrast:

logout:
useBlur: true

startupfeedback:
type: 1

screenedge:

kscreen:

Have you tested Plasma on clean configuration or on new (testing) user?

No, I have not, which reminds me of an important detail I should have mentioned earlier: I have no way to reliably reproduce the freezes. They happen only ~10 times per day if I work + switch desktops a lot or once every 2-3 days if I don't.

V1del · 2016-08-02 12:52:30

Just from what we have here, have you tried with the OpenGL 3.1 backend instead of the OGL2 backend? You mentioned tearing issues, but how have you had them resolved? There were multiple ways mostly using env variables, I know I currently still use __GL_YIELD=USLEEP to prevent tearing (there was a time where it was necessary to also have KWIN_EXPLICIT_SYNC=0 but I don't use that anymore right now ), what also might have an effect, what kind of applications do you have open and switch to/from? Certain OpenGL applications can cause strange interferences with KWin, there's currently an unresolved bug that breaks Breeze shadows when using an OpenGL application which requests exclusive fullscreen.

whoops · 2016-08-02 13:25:35

V1del wrote:

Just from what we have here, have you tried with the OpenGL 3.1 backend

Oh, didn't know 3.1 is working now (last time I tried it out it was just crashing). I switched & will try it now, thanks!

You mentioned tearing issues, but how have you had them resolved?

I've been using "ForceFullCompositionPipeline" in xorg.conf.d for a long long time until it broke with a recent nvidia update and prevented X from starting. Then I just started setting it manually with nvidia-settings (on demand / before I watch video). I will stop using it at all for a while, to see if it has anything to do with the freezes - thanks for reminding me that not everyone has that active! I wasn't aware people were using other options to get rid of tearing...

Certain OpenGL applications can cause strange interferences with KWin, there's currently an unresolved bug that breaks Breeze shadows when using an OpenGL application which requests exclusive fullscreen.

I'm not using any new applications since the freezes happen - just clawsmail, firefox, lots of xfce4-terminals, dolphin, smplayer / mpv... and I don't have any full screen windows... except maybe for mpv sometimes and as far as I can remember, the freezes never happened while I was using that. So, probably unrelated - but just to be on the safe side, I'll use smplayer maximized instead of Fullscreen for a while and remove KDE-Connect for a while too (those notifications from my phone have weird shadows and could be a "chaotic factor").

Last edited by whoops (2016-08-02 13:27:32)

V1del · 2016-08-02 13:58:44

Nah kdeconnect shouldn't have any bearance and the notification popups are courtesy of plasma/knotify, there would be a lot more breakage if they were the cause. OGL 3.1 backend has been working for ages for me, I don't remember it ever being unstable. Afaik (totally unverified, untested and not scientifically measured claim) you shouldn't use the full composition pipeline if you actually have a compositor running (which kwin is one of) they are going to bite each other.

Also fullscreen is a bit of a broad term, I don't think video players and the like are affected, it mostly happens with SDL based games that basically request a screen resolution change. The simple act of going fullscreen while using the normally available resolution shouldn't pose a problem

Last edited by V1del (2016-08-02 14:58:27)

whoops · 2016-08-03 18:27:27

One of those things might have fixed it:
- Switching to the OpenGL 3.1 backend
- Removing "options nvidia NVreg_RegisterForACPIEvents=1 NVreg_EnableMSI=1" from modprobe.d
- Keeping "ForceFullCompositionPipeline" disabled

If the freezes really have stopped and I'm not just having an insanely lucky freeze-less streak ATM, I'd guess it was probably the backend switch that did the trick. I'll have to work with different settings for a week or so before I can be totally sure though.

edit: still testing / waiting...
edit: whyyyyyyyyy!?!?! T_T Can't reproduce at the moment. Can't figure out what changed.

Last edited by whoops (2016-08-05 12:46:01)

whoops · 2016-08-06 13:04:25

So... maybe this thread fixed my problem (thanks!)... somehow?
Have not been able to figure out how. I reverted all the changes I (consciously) made but failed to reproduce the freezes again.
Maybe it was a side-effect of something I did while following advice / information requests in this thread?
Or maybe it was fixed upstream (plasma 5.7.2-2 -> 5.7.3) / just coincidence it happened at the same time...?

Either way "[solved]" I guess, sort of :3

Last edited by whoops (2016-08-08 21:43:04)

whoops · 2016-08-08 22:09:19

Freezes are back... don't know why. No matter the settings I previously experimented with (tested them all, even an exact backup from the time when I had no freezes at all for several days / see above).

So I:
- Purged xorg settings again, ran nvidia-xconfig
- Removed all custom kernel module settings (most of them were ancient workarounds I didn't need anymore anyway)
- Rebooted for the 100th time this week.

... and confirmed freezes still happen. And now I'm starting over with my search - again.

I'll log dmesg to hd from now on every boot so I can compare the output if I ever get a boot that is freeze-free for days again... not sure if that even makes sense or what I should be looking for.

Any other ideas?

V1del · 2016-08-08 23:59:21

coredumpctl contains crash dumps of software , post your Xorg logs (running nvidia-xconfig is basically never a good solution to anything don't do it and remove the config it generated) have you tried what I mentioned? (i.e. exporting

__GL_YIELD=USLEEP

in /etc/profile or similar) can you post a

printenv

for comparisons sake. Are you sure that the graphics card is the crashing factor? What kind of CPU do you have? Have you done the microcode updates on modern intel (up to Broadwell) or firmware updates of your UEFI/BIOS?

whoops · 2016-08-09 08:48:51

- Oh... coredumpctl is kind of empty (I think I disabled coredups a year ago because some program I was working with at that time kept taking huge dumps every 10 minutes). I'll reactivate it as soon as I figure out how I disabled it, but since kwin doesn't halt / crash / etc (it freezes with 100% of one cpu core), I don't have big hopes on that one. I'll try to attach strace next time it happens.
- nvidia-xconfig: I've only been running it intermittently when I ran out of ideas and the xorg.conf it created never seemed to change anything. But, yes, I'll stop with that nonsense now and delete the conf.
- I thought "__GL_YIELD" was for preventing screen tearing? I just stopped using any screen tearing fixes... but I'll try it out now anyway.
- If you mean switching to OGL3.1: That I did.

I can't think of any relevant environment variables I might have changed - especially not in the last half year and the freezes haven't been around for that long. But here's the output of printenv:

HOME=/home/user
LESS_TERMCAP_so=
LANG=de_DE.UTF-8
SHLVL=4
XDG_VTNR=1
KDE_SESSION_VERSION=5
PWD=/home/user
LANGUAGE=en_GB:en_US:de
LOGNAME=user
LESS_TERMCAP_us=
HG=/usr/bin/hg
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
KDE_SESSION_UID=1000
XDG_RUNTIME_DIR=/run/user/1000
MAVEN_OPTS=-Xmx512m
XAUTHORITY=/tmp/xauth-1000-_0
COLORTERM=yes
XDG_SESSION_ID=c1
DISPLAY=:0.0
PYTHONDOCS=/usr/share/doc/python/html/library
LESS= -R 
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/user/.gtkrc-2.0:/home/user/.config/gtkrc-2.0
WINDOWPATH=1
GTK_RC_FILES=/etc/gtk/gtkrc:/home/user/.gtkrc:/home/user/.config/gtkrc
SESSION_MANAGER=local/arch:@/tmp/.ICE-unix/770,unix/arch:/tmp/.ICE-unix/770
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
LESSOPEN=| /usr/bin/source-highlight-esc.sh %s
MAIL=/var/spool/mail/user
LESS_TERMCAP_mb=
LESS_TERMCAP_md=
WINEDLLOVERRIDES=winemenubuilder.exe=d
LESS_TERMCAP_me=
DIRSTACKFILE=/home/user/.zdirs
XDG_DATA_DIRS=/usr/share:/usr/share:/usr/local/share
SHELL=/bin/zsh
XCURSOR_THEME=breeze_cursors
GRADLE_HOME=/usr/share/java/gradle
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
WINDOWID=44040247
QT_AUTO_SCREEN_SCALE_FACTOR=0
TERM=xterm
WINEARCH=win32
PAGER=less
EDITOR=nano
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/scripts/:/home/scripts/
LESS_TERMCAP_se=
XCURSOR_SIZE=0
USER=user
KDE_FULL_SESSION=true
LESS_TERMCAP_ue=
GS_LIB=/home/user/.fonts
XDG_CURRENT_DESKTOP=KDE
XDG_SEAT=seat0
KDE_MULTIHEAD=false
_=/usr/bin/printenv
OLDPWD=/etc/default
LC_MESSAGES=C

- I'm - of course - not sure it's the graphics card. The only reason I assume that is because the freezes happen mostly while compositing animations are running. Most of the time while I "zoom out" to switch desktops, but as far as I can tell not exclusively. Should I focus on areas other than the graphics card?
- I have a "AMD Phenom(tm) II X6 1090T Processor" so having the microcode update should be done automatically, right?

[    9.897171] microcode: CPU5: new patch_level=0x010000dc
[ 2822.125216] microcode: CPU0: new patch_level=0x010000dc

- I have a M4A88TD-V EVO/USB3 - according to the ASUS support site, the last BIOS update for that was "2301" from 2012, which might have been before I bought it (don't remember ever having updated that BIOS myself):

[    0.000000] DMI: System manufacturer System Product Name/M4A88TD-V EVO/USB3, BIOS 2301    08/09/2012
[Di 16/08/09

V1del · 2016-08-09 09:25:43

The __GL_YIELD variable changes the way the nvidia driver does its thread scheduling, the tearing prevention resulting from it is a side effect, because it was racing with KWin during rendering. So it might help if there is some threading conflict. Yes AMD processors should get their microcodes automatically and I remember that there have been some reports that the 4.6 kernel had (has?) issues with AMD processors although you mention having tried with the LTS kernel already, it might be that its something in that direction. But yeah reenabling crash dumps might help get closer at the issue

whoops · 2016-08-13 20:15:21

Reactivated coredumps. None happen during the freezes, so no new data here...
Also added __GL_YIELD=USLEEP to /etc/environment. That didn't seem to change anything.
Then I waited for the 4.7 kernel (and another freeze) - still the same problem.

Freezes happen about 1-3 times per day at the moment - which seems less frequent - haven't been able to figure out a reason for this. Maybe it's (mostly) the desktop pane switch / zoom effect in conjunction with using multiple X-Sessions and I just haven't been switching Desktops (or TTYs) so often? *sigh* or that might just be my imagination.

strace looked... slow... and useless... maybe? Nothing in there I was able to read. Not sure if it makes any sense posting stuff like that and if I have to sanitize the output somehow... no idea what kind of data can or can't end up in there... since I can't read it... argh. Probably that kind of output is useless in such cases anyway?

I remember that there have been some reports that the 4.6 kernel had (has?) issues with AMD processors although you mention having tried with the LTS kernel already, it might be that its something in that direction.

whoops · 2016-08-21 18:02:07

I think it has something to do with the "Desktop Grid" settings, maybe "Present Windows". I changed ALL THE SETTINGS there and the Freezes seem to be gone... I hadn't changed anything there in a long time, so it must be some sort of regression. No idea how to figure out where to go with this problem... not totally sure yet...

If anyone has an idea how I could speed this up: at the moment I have to check different combinations of settings for some days (since I can't reproduce the bug reliably)... and once I'm done... no idea what to do then... there has to be a more sensible approach?

Last edited by whoops (2016-08-21 18:04:06)

v3ss0n · 2016-08-22 23:29:17

Hi , I am a Sabayon Linux user with same KDE and Kernel setup as you and we are having same problem.
Hardware : Intel Haswell , but Geforce disabled.
Linux 4.6.4
Kwin 5.7
Opengl 3.1
- Freezes when destkop switching (desktop grid effect)
- Freezes a lot at first then i swtch to scale method to "Accurate"
- Then Freeze become partial freeze , freeze can recover sometime from freezing about 3 mins But still freezes sometime (Reduced to 1-2 times a day).
Desktop grid switching is definately the probelm.

Last edited by v3ss0n (2016-08-22 23:29:39)

whoops · 2016-08-24 10:40:07

What does "geforce disabled" mean? One of those Bumblebee things (/ intel driver)?
Did you have any luck pinpointing an update that might have started the problems?

Sounds like this might have been introduced by plasma 5.7 after all, not nvidia?

I haven't had any freezes at all since I deactivated "present windows"... I guess that means it's just about time to carry this to the KDE bugtracker?

vegangaro · 2017-07-08 16:03:59

Same problem here.

Arch Linux up to date
KDE 5.10

I just give up desktop grid and disabled it! I will just switch through shortcuts and Latte dock! haha

V1del · 2017-07-08 22:58:43

Please don't necrobump solved topics, your issue is likely different.

Closing.

Arch Linux

#1 2016-08-02 09:35:32

[solved] kwin_x11 / Plasma / Compositing freezes

#2 2016-08-02 10:54:39

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#3 2016-08-02 11:38:14

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#4 2016-08-02 12:19:15

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#5 2016-08-02 12:52:30

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#6 2016-08-02 13:25:35

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#7 2016-08-02 13:58:44

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#8 2016-08-03 18:27:27

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#9 2016-08-06 13:04:25

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#10 2016-08-08 22:09:19

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#11 2016-08-08 23:59:21

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#12 2016-08-09 08:48:51

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#13 2016-08-09 09:25:43

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#14 2016-08-13 20:15:21

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#15 2016-08-21 18:02:07

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#16 2016-08-22 23:29:17

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#17 2016-08-24 10:40:07

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#18 2017-07-08 16:03:59

Re: [solved] kwin_x11 / Plasma / Compositing freezes

#19 2017-07-08 22:58:43

Re: [solved] kwin_x11 / Plasma / Compositing freezes

Board footer