Rather struggling with this one, any pointers welcome.
I’ve a system here which started as 42.2 then “DUPed” to 42.3 - It runs the KDE desktop and has an nvidia GT710 card which has been running perfectly OK using the proprietary nvidia “G04” driver installed from https://download.nvidia.com/opensuse/leap/[relavent version].
Following a “DUP” to 15.0 I now have a rather strange, (and somewhat annoying) video problem:
All appears to be OK…
… until one switches to a virtual terminal and then return to the graphics desktop.
Upon doing that a message pops up from KWin Window Manager “Desktop effects were restarted due to a graphics reset”, from that point on I have a very unstable graphics environment. For example, if I open an application that leaves some desktop visible, the application’s window is fine but the remaining desktop is flickering.
If I log out from the KDE session and re-login all is OK once more. (Provided I don’t switch to and from a VT).
If I disable compositing, or use xrender as the backend I don’t see the problem at all, (it only occurs if using OpenGL 2.0 or 3.1)
This happens with both the GO4 (390.116) and G05 (418.43) drivers.
paul@Orion-17:~> uname -a
Linux Orion-17.openSUSE 4.12.14-lp150.12.48-default #1 SMP Tue Feb 12 14:01:48 UTC 2019 (268f014) x86_64 x86_64 x86_64 GNU/Linux
paul@Orion-17:~>
(kernel 4.4.165-81.1 and 4.4.172-86.1 are from the previous 42.3)
A further observation when the desktop background is flickering…
The flickering is fast and erratic if there is mouse movement, otherwise it flickers at a rate of once per second as the seconds on the digital clock update…
This is the effect when it’s flickering at 1Hz, the background alternates between the correct desktop display and black.
Xorg.0.log is after reboot, switch to VT and back (same Kwin message upon switching back to graphics desktop), temporarily disabled compositing (shift-alt-f12).
Yes, I’ve tried the G05 (418.43) driver, same result…
My options at the moment seem to be either turn off compositing, or use the nouveau OSS driver, I’ll probably go for the latter if I can’t find an immediate solution. Perhaps it will “magically” solve itself when I go to 15.1, though I doubt I’ll do that until a couple of months after it’s release.
Or the upstream default, merged into server 1.17.0 49 months ago from the former xf86-video-modesetting. No NVidia user except me seems to know it exists, much less use it.
That however seems to result in the system using the framebuffer driver, or am I misinterpreting the output from inxi?
NVidia uninstallation isn’t complete. Simply removing NVidia’s rpms is not sufficient. The uninstallation instructions that accompanied the NVidia installer must be followed precisely. Otherwise, intrusive changes the proprietary installer made can linger in /etc/modprobe.d/, initrds, /lib/ and/or bootloader config.
The proprietary driver (from Index of /opensuse/leap/15.0 ) was installed / uninstalled using YaST2 Software Management. Does that not clean up properly after removal?
Otherwise, intrusive changes the proprietary installer made can linger in /etc/modprobe.d/, initrds, /lib/ and/or bootloader config.
What changes should I be specifically looking for?
I’d expect any reasonable person to expect it to, but I don’t know. Based on trouble I’ve seen people report in forums and mailing lists, it’s quite possible that it doesn’t. YaST has had a lot of rewriting in recent years. That to me means expect breakage, especially WRT software that can’t go through QA. People confronted with the problem tend to reinstall the whole OS in frustration rather than trying to muddle through what didn’t happen trying to get it gone.
[quote]Otherwise, intrusive changes the proprietary installer made can linger in /etc/modprobe.d/, initrds, /lib/ and/or bootloader config.
What changes should I be specifically looking for?[/QUOTE]As one who has never tainted his own FOSS Linux PC installations with a proprietary video driver, I can’t answer with much specificity. /etc/modeprobe.d/ would have nouveau blacklisted. Initrds probably need to be rebuilt after all other eradication of proprietary changes are complete. Bootloader configuration might include a nomodeset or nouveau.modeset=0 cmdline parameter that needs to be purged. What library(s) might be changed I don’t know how to determine. File dates in /lib/ might provide a clue.
I didn’t realise I was buying a one way ticket with the “easy” install…
I’ve had a cursory glance around, there doesn’t appear to be anything of significance in /etc/modprobe.d/, either as a separate file or in the contents of 50-blacklist.conf. The kernel command line is as I set it (a couple of iommu entries needed for this amd motherboard), so nothing there either.
I really don’t want to go down the complete reinstall road… I’ll reinstall the nvidia proprietary driver and just live with the bug, it does, after all, only occur if I switch to and from a virtual terminal without logging out from KDE, so it’s no major killer.
Thanks for the suggestion… but… (and I note your signature line) I really don’t want to risk breaking that particular machine, either now or on future updates. I’ll live with the bug.
When I last tried that (around 2 years ago, running 13.2), not it did not clean up properly. After the removal, graphics was badly broken. A forced reinstall of Mesa (actually several packages with “Mesa” as part of the name) fixed it.
