<Hey user, I need a short break, but won’t tell you why>
But I will stop for a beer break now so hang in there, be back in a few!
I get no click response, keyboard responses, or anything else until something in the system decides it is ready gor mr to use it again.
Where do I look for things to maybe answer why it does this? It isn’t consistent, but it does happen nearly every evening while I am using Leap.
PS> I believe it is KDE started via lightDM. Not sure about KDE but am sure of lightDM
Are we talking about brief times eg 1-2s or significantly longer times? When it occurs, can you still toggle the CAPS LOCK light (instantly) when the key is pressed? If not, that can indicate a possible issue with the X-server.
Which compositing backend is in use currently? Sometimes that can cause issues with some graphics hardware. That can be checked via System Settings > Display and Monitor > Compositor
or run the following command (filtered for compositor-related output)…
qdbus org.kde.KWin /KWin supportInformation|grep Comp
and report back.
PS> I believe it is KDE started via lightDM. Not sure about KDE but am sure of lightDM
I’m sure that you know which desktop environment your computer is using Bill. 
In any case, your desktop can confirm with…
echo $DESKTOP_SESSION
echo $XDG_CURRENT_DESKTOP
It is KDE and Plasma5
And the delays are a minute or more at times. They are somewhat near the time the desktop is loaded in and I select something to do, and then it does it’s stop for a while thing.
Here is the compositing output requested.
localhost:~> qdbus org.kde.KWin /KWin supportInformation|grep Comp
**Comp**osite: yes; Version: 0x4
use**Comp**ositing: true
windowsBlock**Comp**ositing: true
**Comp**ositing
**Comp**ositing is not active
Something seems off there in the last two lines compared to the first three lines.
Do you want a capture of the Display and Monitor compositor window. Currently is it OpenGL2 with options for OpenGL3 and xrender
Yes, it is reported as inactive. Not sure why though. Try activating with
qdbus org.kde.KWin /Compositor resume
then check compositing status again.
Do you want a capture of the Display and Monitor compositor window. Currently is it OpenGL2 with options for OpenGL3 and xrender
No, that’s ok Bill. In any case the settings are in ~/.config/kwinrc, and you can get them with
cat ~/.config/kwinrc
However, I’m not convinced that this is causing the ‘freezing’ symptoms that you describe.
after doing the ‘resume’ thing you suggested above’
I still get this; same results.
localhost:~> qdbus org.kde.KWin /KWin supportInformation|grep Comp
**Comp**osite: yes; Version: 0x4
use**Comp**ositing: true
windowsBlock**Comp**ositing: true
**Comp**ositing
**Comp**ositing is not active
bill@localhost:~>
And this at the top of the console after doing the
cat ~/.config/kwinrc
@localhost:~>
[Compositing]
OpenGLIsUnsafe=true
Ah, that would explain why compositing is disabled. Some older Intel hardware for example behaves better with XRender for composition, instead of OpenGL. Try configuring with the xrender backend, or consider disabling it in System Settings.
Which X driver is actually in use, Intel (xf86-video-intel) , or Modesetting (integral to server, not separate package)?
inxi -Gxx
will report if you don’t know (Xorg.0.log reports also, but very much more verbosely). Switching between the two might be worth trying, but when I see pauses like you describe I first suspect journaling system bloat or snapshotting. How many files are in /var/log/journal/*/? How much freespace is on the / filesystem?
inxi
Not recognized.But from ‘Xorg.0.log’ I am assuming X11.
A few less than 30 in the /var/log/journal directory.
“/” has 27.1GiB freespace.
I will give XRender try for a few days.
You need to install ‘inxi’ first.
zypper in inxi
grep '(0)' /var/log/Xorg.0.log
will demonstrate what I meant by more verbosely. Here the result is 156 lines. Driver in use prepends each (0) in the output. Meanwhile,
inxi -Gxx
looks thus:
Graphics: Device-1: Intel 4th Generation Core Processor Family Integrated Graphics driver: i915 v: kernel
bus ID: 00:02.0 chip ID: 8086:041e
Display: server: X.Org 1.18.3 driver: modesetting unloaded: fbdev,vesa alternate: intel
resolution: 1920x1200~60Hz
OpenGL: renderer: Mesa DRI Intel Haswell v: 4.3 Mesa 17.0.5 compat-v: 3.0 direct render: Yes
which shows not only kernel and X drivers in use, but also available alternative X drivers, among other potentially useful troubleshooting info.
I suggest also doing
zypper in command-not-found
to prompt a useful next step when a command someone trying to help you asked you to run doesn’t seem to have been fruitful.
Thanks deano_ferrari and mrmazda, more lessons learned.
Results of lnxi -Gxx:
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
**Graphics: ****Card:**Advanced Micro Devices [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series]
**bus-ID:**01:00.0**chip-ID:**1002:68f9
**Display Server:**X.org 1.19.6 **drivers:**ati,radeon (unloaded: modesetting,fbdev,vesa)
**tty size:**195x62 **Advanced Data:**N/A for root
I changed to XRender yesterday, but it doesn’t show up in the above.
I colored the red stuff, it came out pale in the console.
Tried that , it resulted in 'Already installed, nothing to do.
OOPS! forgot to add up above that it still takes a break, but not as long as it had been doing. Sometimes fractions of a second, sometimes just over a minute.
Still disconcerting.