KDE desktop overlayed and eventually hangs

I have installed LEAP 15.1 on a desktop with an NVIDIA G72 Board - p385h0 and am using KDE. Periodically the desktop is overlayed by what appears to be wallpaper. Sometimes my open applications reappear. Eventually KDE stops responding to left and right clicks, although I can still move the cursor.

What diagnostic data should I collect before reporting the bug?

A slightly more detailed description of the graphics adapter:

NVIDIA RIVA-128, RIVA-128ZX, RIVA-TNT, RIVA-TNT2, RIVA-TNT2 M64
NVIDIA RIVA-TNT2 Vanta, RIVA-TNT2 Ultra, GeForce 256, GeForce DDR
NVIDIA Quadro, GeForce2 Integrated GPU, GeForce2 Ti, GeForce2 GTS
NVIDIA GeForce2 MX 100/200, GeForce2 MX/MX 400, GeForce2 Ultra
NVIDIA GeForce4 MX 420, GeForce3, Quadro2, GeForce4 MX 440
NVIDIA GeForce4 MX 440 8X, GeForce4 MX 460, GeForce4 MX 4000
NVIDIA GeForce4 Integrated GPU, GeForce4 Ti 4200, GeForce4 Ti 4200 8X
NVIDIA GeForce4 Ti 4400, GeForce4 Ti 4600, GeForce4 Ti 4800
NVIDIA Quadro4 NVS, Quadro4 XGL, GeForce FX 5200, GeForce FX 5500
NVIDIA GeForce FX 5600 Series, GeForce FX 5700 Series, Quadro FX
NVIDIA GeForce PCX 5300, GeForce PCX 5750, GeForce 6200 Series
NVIDIA GeForce 6600 Series

The better identification of the Graphics adapter comes from the PCI Device ID, which can come from either of these (among others):

lspci -nnk | grep -A3 VGA
inxi -Gxx

Inxi should be run from Xterm or Konsole.

https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units

G72 = GeForce 7200/7300/7500 series.
It is too old - 2006 year.
Looks like you are using nouveau driver, which works badly with KDE.
Try to disable OpenGL acceleration in KDE - use XRender instead.
Or try to install Nvidia proprietary driver - you will need G02 from https://download.nvidia.com/opensuse/leap/42.3/x86_64/ .

Or change videocard.
If you want to use old one then try ATI/AMD hardware - it still works with Mesa drivers.
Radeon HD X2000 series (Terascale) or newer are good enough.

What file do I need to edit, or what Yast option, to disable OPENGL and use xrender?

Right now my primary system is OS/2, and if I changed cards I need to deal with driver issues.

Thanks.

G84 (spring 2007) is only a year or so newer than G72. It still seems to work fine with Mesa in TW, so should still in 15.1:

> pinxi -V | head -n1
pinxi 3.0.37-38 (2020-02-24)
> pinxi -SGxx
System:    Host: big41 Kernel: 5.4.14-1-default x86_64 bits: 64 compiler: gcc v: 9.2.1 Desktop: KDE Plasma 5.17.5
           tk: Qt 5.14.0 wm: kwin_x11 dm: N/A Distro: openSUSE Tumbleweed 20200128
Graphics:  Device-1: NVIDIA **G84** [GeForce 8600 GT] vendor: XFX Pine driver: nouveau v: kernel bus ID: 01:00.0
           chip ID: 10de:0402
           Display: **x11 server: X.Org 1.20.7 driver: modesetting** unloaded: fbdev,vesa alternate: nouveau,nv,nvidia
           compositor: kwin_x11 resolution: 1920x1200~60Hz
           OpenGL: renderer: llvmpipe (LLVM 9.0.1 128 bits) v: 3.3 Mesa 19.3.2 compat-v: 3.1 direct render: Yes

Maybe the problem would be solved by simply removing xf86-video-nouveau? As you can see, I am using the (upstream default) modesetting DDX](https://en.wikipedia.org/wiki/X.Org_Server#DDX), which is running on the default OpenGL 2.0.

FWIW, it’s been at least 18 years since I’ve used anything but ATI for eCS, because of its superior proprietary DOS mode support.

Hereś the lspci:

ARCAOS-40ADEE0:/opt/DFsee/dfsee_install/linux # lspci -nnk | grep -A3 VGA
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G72 [GeForce 7300 LE] [10de:01d1] (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:0274]
        Kernel driver in use: nouveau
        Kernel modules: nouveau

After installing inxi:

ARCAOS-40ADEE0:/opt/DFsee/dfsee_install/linux # inxi -Gxx
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
Graphics:  Card: NVIDIA G72 [GeForce 7300 LE] bus-ID: 02:00.0 chip-ID: 10de:01d1
           Display Server: x11 (X.org 1.20.3 ) drivers: nouveau (unloaded: modesetting,fbdev,vesa)
           tty size: 107x31 Advanced Data: N/A for root

I´ḿ a complete newbie when it comes to configuring X. Is that a line in a file (which?) or something to configure with Yast?

FWIW, it’s been at least 18 years since I’ve used anything but ATI for eCS, because of its superior proprietary DOS mode support.

I had really bad experience with ATI drivers on OS/2 and windows 3.

It’s a package management action, much like uninstalling a .wpi or using yum.

sudo zypper remove xf86-video-nouveau

will remove the nouveau DDX, which should cause the next start of X to use the modesetting DDX instead. If the result proves unsatisfactory, you can reverse it with

sudo zypper install xf86-video-nouveau

YaST Software Management can be used instead of zypper.

Alternatively, either nouveau or modesetting can be explicitly specified via the file /etc/X11/xorg.conf.d/50-device.conf.

I had really bad experience with ATI drivers on OS/2 and windows 3.
In those days I was happy with Tseng video performance, though not with getting the Tseng OS/2 driver installed.

Thanks; I’ll try that.

I’m a bit leary of editing files updated by Yast; I’ve had cases where Yast rebuilt the file from its own data, overwriting my changes. That a long time ago, so I don’t know whether the issue still exists.

If anything,

zypper remove xf86-video-nouveau

made things worse.

What about xrender? I couldn’t find a package with that name.

I’d like to see /var/log/Xorg.0.log before and after the change.

susepaste -n shmuelmetz -e 10080 /var/log/Xorg.0.log

should do it, though it may claim failure. Whether it in fact failed can be tested by visiting http://susepaste.org to see if any paste by shmuelmetz showed up in recent minutes. The resulting URL found there can be pasted here.

What about xrender? I couldn’t find a package with that name.
I have no idea what engages that or not.

It’s a setting.

Configure Desktop → Display and Monitor → Compositor → Rendering Backend

Another possibility that you could try, is to set

LIBGL_ALWAYS_SOFTWARE=1

in your environment. You would need to set that in ~/.profile or similar startup file, so that it is set before your desktop starts.

Do I need all three?


nvidia-computeG02-304.137-22.1.x86_64.rpm
nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64.rpm
x11-video-nvidiaG02-304.137-22.1.x86_64.rpm 

I tried that and got

ARCAOS-40ADEE0:~ # zypper in https://download.nvidia.com/opensuse/leap/42.3/x86_64/nvidia-computeG02-304.137-22.1.x86_64.rpm \
>  https://download.nvidia.com/opensuse/leap/42.3/x86_64/nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64.rpm \
>  https://download.nvidia.com/opensuse/leap/42.3/x86_64/x11-video-nvidiaG02-304.137-22.1.x86_64.rpm
Loading repository data...
Reading installed packages...
Resolving package dependencies...
3 Problems:
Problem: nothing provides ksym(default:PDE_DATA) = 8c971ed4 needed by nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64
Problem: nothing provides ksym(default:PDE_DATA) = 8c971ed4 needed by nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64
Problem: nothing provides ksym(default:PDE_DATA) = 8c971ed4 needed by nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64

Problem: nothing provides ksym(default:PDE_DATA) = 8c971ed4 needed by nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64
 Solution 1: do not install nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64
 Solution 2: break nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): 1

Problem: nothing provides ksym(default:PDE_DATA) = 8c971ed4 needed by nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64
 Solution 1: do not install nvidia-computeG02-304.137-22.1.x86_64
 Solution 2: break nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): 1

Problem: nothing provides ksym(default:PDE_DATA) = 8c971ed4 needed by nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64
 Solution 1: do not install x11-video-nvidiaG02-304.137-22.1.x86_64
 Solution 2: break nvidia-gfxG02-kmp-default-304.137_k4.4.76_1-22.1.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): 1
Resolving dependencies...
Resolving package dependencies...

Nothing to do.
ARCAOS-40ADEE0:~ #

I repeated my request for Xorg.0.log to OP privately. He did so. I see nothing in them to indicate X is his problem. He’s currently using the modesetting DDX.

Next I suggest two things to help try to determine what’s going wrong:

  • go into System Settings > Display & Monitor > Compositor and deselect enable compositor on startup, then restart Plasma
  • at the SDDM login greeter, choose an IceWM session instead of Plasma
    Do either of these avoid the problem? If so, most likely Plasma is the problem, not a video driver or gfxcard.

There may be clues in ~/.xsession-errors. If it’s small, it can be pasted in here using code tags. If large, then uploading to http://susepaste.org would be better.

More clues might be found via dmesg and/or journal:

sudo journalctl -b | grep -i failed
sudo dmesg | grep -i failed

could provide starting points for closer examination of those logs. Again, either paste here if small, or upload if not.

Another option might be to swap GPUs if another is available, and just not boot ArcaOS until after determining whether a GPU change helps.

Deselecting compositor on startup leads to smother scrolling, but VLC won’t start.

Running under root I can’t find ~/.xsession-errors:

ARCAOS-40ADEE0:~ # ls ~/.*
/root/.Xauthority  /root/.bash_history  /root/.directory  /root/.gtkrc-2.0  /root/.xauthCRdsn5  /root/.xauthodXMtZ

However, /home/shmuel/.xsession-errors-:0 has over a thousand lines. https://susepaste.org/11149290

The output of the suggested commands is:

ARCAOS-40ADEE0:~ # journalctl -b | grep -i failed
Mar 03 14:44:43 localhost kernel: acpi PNP0A08:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
Mar 03 14:44:45 localhost systemd-vconsole-setup[260]: KD_FONT_OP_GET failed while trying to get the font metadata: Function not implemented
Mar 03 14:45:16 localhost nscd[743]: 743 stat failed for file `/etc/resolv.conf'; will try again later: No such file or directory
Mar 03 14:45:17 localhost avahi-daemon[803]: Failed to open /etc/resolv.conf: No such file or directory
Mar 03 14:45:17 localhost systemd[1]: smartd.service: Unit entered failed state.
Mar 03 14:45:17 localhost systemd[1]: smartd.service: Failed with result 'exit-code'.
Mar 03 14:45:18 localhost systemd-udevd[434]: Process '/usr/sbin/alsactl restore 0' failed with exit code 99.
Mar 03 14:46:00 ARCAOS-40ADEE0 kwin_x11[1674]: "\"fsrestore1\" - conversion of \"0,0,0,0\" to QRect failed"
Mar 03 14:46:01 ARCAOS-40ADEE0 org_kde_powerdevil[1720]: powerdevil: org.kde.powerdevil.backlighthelper.brightness failed
Mar 03 14:46:27 ARCAOS-40ADEE0 dbus-daemon[812]: [system] Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
Mar 03 17:31:29 ARCAOS-40ADEE0 baloo_file[4853]: Failed to register via dbus. Another instance is running
Mar 03 17:31:29 ARCAOS-40ADEE0 kwin_x11[4851]: "\"fsrestore1\" - conversion of \"0,0,0,0\" to QRect failed"
Mar 03 17:31:29 ARCAOS-40ADEE0 kwin_x11[4851]: "\"fsrestore2\" - conversion of \"0,0,0,0\" to QRect failed"
Mar 03 17:31:31 ARCAOS-40ADEE0 org_kde_powerdevil[4900]: powerdevil: org.kde.powerdevil.backlighthelper.brightness failed
Mar 03 17:31:59 ARCAOS-40ADEE0 dbus-daemon[812]: [system] Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
Mar 03 17:31:59 ARCAOS-40ADEE0 kdeinit5[4822]: org.kde.bluez: PendingCall Error: "Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)"
Mar 03 20:15:38 ARCAOS-40ADEE0 kernel: sr 3:0:0:0: [sr1] tag#29 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Mar 03 20:15:38 ARCAOS-40ADEE0 kernel: sr 3:0:0:0: [sr1] tag#30 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Mar 03 20:15:39 ARCAOS-40ADEE0 kernel: sr 3:0:0:0: [sr1] tag#10 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Mar 03 20:15:39 ARCAOS-40ADEE0 kernel: sr 3:0:0:0: [sr1] tag#13 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
ARCAOS-40ADEE0:~ # 

ARCAOS-40ADEE0:~ # dmesg | grep -i faile
    0.179893] acpi PNP0A08:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[19857.336606] sr 3:0:0:0: [sr1] tag#29 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[19857.392552] sr 3:0:0:0: [sr1] tag#30 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[19857.984547] sr 3:0:0:0: [sr1] tag#10 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[19858.104561] sr 3:0:0:0: [sr1] tag#13 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
ARCAOS-40ADEE0:~ # 

A good sign.

but VLC won’t start.
VLC will not start as root. It’s one of those apps that* knows* better than the superuser what the superuser should be capable of doing with his own system.

Running under root I can’t find ~/.xsession-errors:
Good! :slight_smile:

However, /home/shmuel/.xsession-errors-:0 has over a thousand lines.
That file has no timestamps, could be indicating problems already solved by the DDX switch. Please log out of Plasma and remove that file, then start Plasma, log right back out, then look at it, if it has been recreated already at that point.

Next it might be worth deleting all files in ~/.cache/ while logged out of Plasma, to see how well things go with a fresher normal user.

The output of the suggested commands is:

# journalctl -b | grep -i failed
...
# dmesg | grep -i faile
...

I don’t see anything in those I recognize as cause of your observed trouble. That’s not to say there isn’t, just that I’m not up to speed of most of their meanings. My Intel 4 Series only has Plasma on TW. This is what I get there:

# dmesg | grep -i ailed
    0.400948] acpi PNP0A08:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
# journalctl -b | grep -i ailed
Mar 02 19:52:49 big41 kernel: acpi PNP0A08:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
Mar 02 19:52:53 big41 systemd[1]: haveged.service: Failed with result 'exit-code'.
Mar 03 00:52:57 big41 nscd[586]: 586 stat failed for file `/etc/services'; will try again later: No such file or directory

It seems to be doing just fine! The last two are about a known problem having nothing I know of to do with Plasma. ACPI errors typically can only be solved if a BIOS upgrade can be installed.

Have you done any zypper dups since installing? If not, next step I suggest is to do so. Once that’s done, try reenabling compositor. It might be these GPUs are so old that that’s a bad idea. I keep mine off. I don’t like many of the effects it allows.

I deleted /home/shmuel/.xsession-errors-:0

I assume that I should leave the sub-directories of ~shmuel/.cache alone and delete only

  • file:///home/shmuel/.cache/icon-cache.kcache
  • file:///home/shmuel/.cache/ksycoca5_en_iwBfheaJ4WcRFeFDC29QXWo8QGQ=
  • file:///home/shmuel/.cache/ksycoca5_en_IxZ8+W+nxexpk6CmuSzbyenGXnc=
  • file:///home/shmuel/.cache/plasma_theme_openSUSE_v0.5.kcache
  • file:///home/shmuel/.cache/plasma-svgelements-openSUSE_v0.5
  • file:///home/shmuel/.cache/qt_compose_cache_little_endian_3f5f5d11b29d4493a86ee4355a63f27c
  • file:///home/shmuel/.cache/qt_compose_cache_little_endian_d7d9920dce2447218be726401dc8a14d

I’ve only used zypper dup for Tumbleweed; isn’t LEAP 15.1 frozen?

Cache is cache, temporary, in theory recreated as needed, but not always done properly. Deleting everything just causes a bit of delay when cache needs to be recreated, less angst than a corrupt cache can cause. I’d delete everything that I’m not certain could have no possible relationship to Xorg or KDE or Plasma or SDDM. It’s easier to eradicate all of it then decide what’s what. KDE/Plasma does have a history of occasionally improving behavior after cache clearing. I clear it myself fairly often.

I’ve only used zypper dup for Tumbleweed; isn’t LEAP 15.1 frozen?
I should have written zypper up. My bad. Then again, ‘zypper dup --from Packman’, if configured and enabled, stands a remote chance of helping - or the opposite. :stuck_out_tongue: