Bug 27945 - nvidia graphic card needing nvidia340 nonfree driver can't have transparency work in Qt Applications
Summary: nvidia graphic card needing nvidia340 nonfree driver can't have transparency ...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-27 14:28 CET by Brian Kimerer
Modified: 2021-02-06 13:25 CET (History)
5 users (show)

See Also:
Source RPM: nvidia340-340.108-15.mga8.nonfree.src.rpm
CVE:
Status comment:


Attachments
System Settings Compositor Warning Image (86.83 KB, image/png)
2021-01-02 21:50 CET, Brian Kimerer
Details
Installed Packages (94.70 KB, text/plain)
2021-01-02 23:04 CET, Brian Kimerer
Details

Description Brian Kimerer 2020-12-27 14:28:56 CET
Description of problem:

I have several programs that I wrote that use transparent backgrounds. I am running an up-to-date Cauldron system. Since a recent update, which I installed on December 8, all of the backgrounds for the programs show up solid black.

To narrow down the problem, I created a very simple main window app in Qt Creator using their desktop app template, and I made the window transparent using the same technique that I used in my other programs, to wit:

#include "mainwindow.h"
#include "ui_mainwindow.h"

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
{
    ui->setupUi(this);
    // Make the MainWindow transparent
    this->setAttribute(Qt::WA_TranslucentBackground);
}

MainWindow::~MainWindow()
{
    delete ui;
}


The only thing I changed in the template created by Qt Creator is adding the this->setAttribute(Qt::WA_TranslucentBackground); call.

On my Mageia 7 computer, the window comes up transparent, but on the Mageia 8 computer it is opaque black.

I have searched the web and tried many suggestions that I found out there for making the window transparent, but none of them fix the problem.

Before the upgrade on Dec 8, all of this was working fine, so I doubt that it is a programming error in my programs.

My inxi info:


$ inxi -b
System:    Host: localhost Kernel: 5.9.12-desktop-1.mga8 x86_64 bits: 64 Desktop: KDE Plasma 5.20.4 Distro: Mageia 8 mga8
Machine:   Type: Desktop Mobo: ASUSTeK model: P5G41T-M LX PLUS v: Rev X.0x serial: <superuser/root required>
           BIOS: American Megatrends v: 0502 date: 10/21/2011
CPU:       Info: Dual Core Intel Core2 Duo E7300 [MCP] speed: 2362 MHz
Graphics:  Device-1: NVIDIA G94 [GeForce 9600 GT] driver: nvidia v: 340.108
           Display: x11 server: Mageia X.org 1.20.10 driver: nvidia,v4l resolution: 1920x1080~60Hz
           OpenGL: renderer: GeForce 9600 GT/PCIe/SSE2 v: 3.3.0 NVIDIA 340.108
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
           Device-2: Realtek RTL-8100/8101L/8139 PCI Fast Ethernet Adapter driver: 8139too
           Device-3: Qualcomm Atheros AR9271 802.11n type: USB driver: ath9k_htc
Drives:    Local Storage: total: 465.76 GiB used: 28.61 GiB (6.1%)
Info:      Processes: 206 Uptime: 3h 57m Memory: 3.84 GiB used: 2.24 GiB (58.4%) Shell: Bash inxi: 3.1.09

I ran the Qt Creator program in IceWM to see if Plasma is causing it. I got the same result as I did with Plasma, the transparency does not work, and the background is solid, opaque black. So I do not think it is a Plasma problem.

To further narrow down which part of the graphics software is at fault I downloaded an example program from

https://github.com/datenwolf/codesamples/blob/master/samples/OpenGL/x11argb_opengl/x11argb_opengl.c

which I found at StackOverflow here

https://stackoverflow.com/questions/4052940/how-to-make-an-opengl-rendering-context-with-transparent-background

The program creates a window with a transparent background using GLX. I compiled this on my Mageia 7 system and it does create a window with a transparent background as expected. When I ran the program that I compiled on Mageia 7 on the Mageia 8 computer it made the window opaque black.

So I compiled the same code on my Mageia 8 computer, and the background is a black rectangle. No change to the code. 

The program uses GLX to open the window, hence it does not use Qt at all, That indicates that the problem lies in the code that underpins the Qt software, not with Qt.

This would also explain why transparency also does not work in conky anymore either.

I suspect that it is a disconnect between X11 and the Nvidia driver. The other graphics seem to work OK.


Version-Release number of selected component (if applicable):


How reproducible:

Always - at least on my graphics hardware.


Steps to Reproduce:
1. Create a generic Qt Widget app in Qt Creator
2. Add setAttribute(Qt::WA_TranslucentBackground); to make background transparent
3. Compile and run the application
Comment 1 Lewis Smith 2020-12-27 16:54:16 CET
Could this be another manifestation of Bug 27884 ?

CC: (none) => lewyssmith

Comment 2 Joe Da Silva 2020-12-27 23:17:26 CET
Bug 27884 appears fixed recently - now running QT5.15.2 (32bit).

Attaching this link as it may contain extra information for this bug:
https://forums.mageia.org/en/viewtopic.php?f=15&t=13813

CC: (none) => digital

Comment 3 Brian Kimerer 2020-12-28 15:25:33 CET
I am running the Nvidia proprietary driver, not VESA or Nouveau driver. I might put the system back on the Nouveau driver temporarily to see if the problem persists without the Nvidia propretary driver. I cannot run on a regular basis with the Nouveau driver because Blender (which goes directly to OpenGL for its interface) crashes when run against the Nouveau driver.

I do not recall any black panels on the Mageia tools, just on the transparent window backgrounds. I can look more carefully.

Last I looked, I was running Qt 5.15.2, and it was that upgrade where my problem appeared. So the fix mentioned in https://bugs.mageia.org/show_bug.cgi?id=27884
doesn't fix this one.
Comment 4 Brian Kimerer 2020-12-28 16:54:24 CET
I set the system up to use the Nouveau driver.

System:    Host: localhost Kernel: 5.10.3-desktop-1.mga8 x86_64 bits: 64 Desktop: KDE Plasma 5.20.4 Distro: Mageia 8 mga8 
Machine:   Type: Desktop Mobo: ASUSTeK model: P5G41T-M LX PLUS v: Rev X.0x serial: <superuser required> 
           BIOS: American Megatrends v: 0502 date: 10/21/2011 
CPU:       Info: Dual Core Intel Core2 Duo E7300 [MCP] speed: 2659 MHz 
Graphics:  Device-1: NVIDIA G94 [GeForce 9600 GT] driver: nouveau v: kernel 
           Display: x11 server: Mageia X.org 1.20.10 driver: nouveau,v4l resolution: 1920x1080~60Hz 
           OpenGL: renderer: NV94 v: 3.3 Mesa 20.3.1 

The transparency still fails. All I get for transparent backgrounds is an opaque black rectangle. That is what I get when I run my GLX window program as well, which bypasses Qt. When I run that program, I can set the color of the transparent background to something other than black, and the color that I set shows up. But the alpha channel is ignored. The background is opaque.

So, the Nvidia proprietary driver is not at fault since I am not running that driver any more. It now looks like X11 might be at fault, although I am not aware of how I can isolate that. It could also be something related to my antique Nvidia card. I don't know if the hardware can fail in such a way or not. I am seeing no odd effects from the graphics card other than the inability to do translucent windows. I checked when I installed Nouveau, and translucency was enabled.

I am not seeing any odd effects in any of the Mageia tools. It is just the transparent backgrounds in the applications.
Comment 5 Joe Da Silva 2020-12-28 23:05:51 CET
Maybe try Xorg-vesa - there is also generic VESA this would exclude the nvidia and any other possible GPU magic
Comment 6 Aurelien Oudelet 2020-12-30 18:58:56 CET
Hi,

I managed to make the code you mentioned in Comment 0
here: https://github.com/datenwolf/codesamples/blob/master/samples/OpenGL/x11argb_opengl/

in order to have this compile, I need to install:
  lib64bsd-devel-0.10.0-2.mga8-x86_64  
  lib64glesv1_cm1-1.3.2-16.mga8-x86_64  
  lib64glvnd-devel-1.3.2-16.mga8-x86_64  
  lib64opengl0-1.3.2-16.mga8-x86_64  
  lib64x11-devel-1.7.0-1.mga8-x86_64  
  lib64xau-devel-1.0.9-2.mga8-x86_64  
  lib64xcb-devel-1.14-1.mga8-x86_64  
  lib64xcb-xf86dri0-1.14-1.mga8-x86_64
  lib64xcb-xtest0-1.14-1.mga8-x86_64
  lib64xcb-xvmc0-1.14-1.mga8-x86_64 
  lib64xdmcp-devel-1.1.3-2.mga8-x86_64
  lib64xrender-devel-0.9.10-3.mga8.x86_64
  libpthread-stubs-0.4-3.mga8-x86_64
  x11-proto-devel-2020.1-2.mga8-noarch

$ make
cc -std=c99 -g3 -o x11argb_opengl -DUSE_GLX_CREATE_CONTEXT_ATTRIB=1 -DUSE_GLX_CREATE_WINDOW=1 x11argb_opengl.c -lX11 -lXrender -lGL -lm

$ ./x11argb_opengl 
FBConfig selected:
Doublebuffer: Yes
Red Bits: 8, Green Bits: 8, Blue Bits: 8, Alpha Bits: 8, Depth Bits: 24
glXCreateWindow

This runs successfully a window with a rotating cube with a correct transparent background. (nvidia-current-455.55.01 with a Geforce GTX 1660 Ti)

So, there is a problem in your setup.

We have switched to glvnd (GL vendor neutral dispatch) so that it should point GL extension to the good library. It appears that the recommended nvidia nonfree driver for your card is 340.108 version (Geforce 9600GT).
Asking QA team members with nvidia340 drivers, if someone can reproduce this bug.

CC: (none) => ouaurelien
Ever confirmed: 1 => 0
Status: NEW => UNCONFIRMED

Aurelien Oudelet 2020-12-30 19:04:07 CET

Source RPM: (none) => nvidia340-340.108-15.mga8.nonfree.src.rpm
Keywords: (none) => 8beta2
Summary: Transparency No Longer Works in Qt Applications => nvidia graphic card needing nvidia340 nonfree driver can't have transparency work in Qt Applications

Comment 7 Brian Kimerer 2020-12-30 20:30:44 CET
I am running nvidia 340.108 again. I did switch over to nouveau for a while to see if the nvidia driver is causing it, but that didn't help, so I switched back.

The hardware on that computer dates back to 2008, so it is about aged out now.

On my other computer (circa 2015) I have Mageia 7 running and using a NVIDIA GM107 [GeForce GTX 750 Ti] card. Everything works there as expected. I have no problems with transparency, so it is clearly something in the setup of my old computer that is causing it.

Thanks for looking into this.

If nobody else with that card can duplicate, then it may just be a strange hardware failure on my system. If nobody else has that card any more, well then the problem is moot.
Comment 8 Lewis Smith 2020-12-30 21:25:53 CET
From comment 0:
> Since a recent update, which I installed on December 8, all of the
> backgrounds for the programs show up solid black.
So this is something that used to work, and stopped working after updates.

Brian, can you do the following to perhaps pin down which relevant looking packages were updated then (unless they have been updated again since):
 $ rpm -qa --last | less
which shows packages grouped in reverse date order. Should have asked this immediately, better hope of identifying it then...
Concentrate on likely culprits, not clearly irrelevant ones.
Comment 9 Joe Da Silva 2020-12-31 05:58:22 CET
Thanks for info on building the sample cube program.
Here are some results running at 32bit, with latest cauldron updates.
If this helps triage extra clues - great!

inxi -b
System:
  Host: genesis Kernel: 5.10.3-desktop-1.mga8 i686 bits: 32 
  Desktop: KDE Plasma 5.20.4 Distro: Mageia 8 mga8 
Machine:
  Type: Desktop System: Dell product: Precision WorkStation 390 v: N/A 
  serial: C8BFXB1 
  Mobo: Dell model: 0GH911 serial: ..CN7082167OH0R0. BIOS: Dell v: 2.6.0 
  date: 05/19/2008 
CPU:
  Info: Dual Core Intel Core2 6700 [MCP] speed: 2660 MHz 
  min/max: 1600/2667 MHz 
Graphics:
  Device-1: NVIDIA NV42GL [Quadro FX 3450/4000 SDI] driver: nouveau 
  v: kernel 
  Display: x11 server: Mageia X.org 1.20.10 driver: nouveau,v4l 
  resolution: 1: 1280x1024~60Hz 2: 1280x1024~60Hz 
  OpenGL: renderer: NV42 v: 2.1 Mesa 20.3.1 

Results:
KDE Plasma runs fine and has transparent background (unfortunately the triangles bug happens - bug which seems to triagulate with window corners).
LXDE shows solid black background
XFCE runs fine with transparent background
IceWM shows solid black background

Now if changing to use Xorg-VESA graphics:
Graphics:
  Device-1: NVIDIA NV42GL [Quadro FX 3450/4000 SDI] driver: N/A 
  Display: x11 server: Mageia X.org 1.20.10 driver: v4l,vesa 
  resolution: 1280x1024 
  OpenGL: renderer: llvmpipe (LLVM 11.0.1 128 bits) v: 4.5 Mesa 20.3.1 

Results:
IceWM shows solid black background
LXDE shows solid black background
XFCE runs faster than IceWM and LXDE, and has transparent background
Plasma runs faster than XFCE and also has transparent background (but it may be faster because it clones second monitor instead of having two_monitor display).
Comment 10 Martin Whitaker 2020-12-31 11:29:44 CET
I tested the sample cube program on the following system:

System:
  Host: localhost Kernel: 5.10.3-desktop-1.mga8 x86_64 bits: 64 
  Desktop: KDE Plasma 5.20.4 Distro: Mageia 8 mga8 
Machine:
  Type: Desktop Mobo: ASUSTeK model: P8H77-V v: Rev X.0x 
  serial: <superuser required> UEFI: American Megatrends v: 1904 
  date: 03/20/2014 
CPU:
  Info: Quad Core Intel Core i5-3550 [MCP] speed: 1600 MHz 
  min/max: 1600/3700 MHz 
Graphics:
  Device-1: NVIDIA G92 [GeForce 8800 GT] driver: nvidia v: 340.108 
  Display: x11 server: Mageia X.org 1.20.10 driver: nvidia,v4l 
  resolution: 1920x1200~60Hz 
  OpenGL: renderer: GeForce 8800 GT/PCIe/SSE2 v: 3.3.0 NVIDIA 340.108 

with a fresh install from cauldron. Following Joe's example, I tested with multiple DEs. Cinnamon, Mate, Plasma, and Xfce gave a transparent background. IceWM and LXDE gave a solid background.

CC: (none) => mageia

Comment 11 Brian Kimerer 2020-12-31 14:57:45 CET
That is an interesting outcome. I only have IceWM and Plasma installed, which both give an opaque background. I will see if I can install another of the DE's that you mention to see what happens on my system.
Comment 12 Martin Whitaker 2020-12-31 15:18:19 CET
Neither IceWM nor LXDE enable a compositor by default, which I think is why they don't support transparency.
Comment 13 Brian Kimerer 2020-12-31 16:31:47 CET
I installed XFCE and the translucent behavior works fine. I ran the program x11argb_opengl, and the transparency works fine. I didn't even recompile the program.

Transparency works fine with my other programs, written in Qt, as well. 

So now I can no longer rule out the Plasma update as a cause for this problem. The problem arose when I installed a large Plasma update on December 8, which is why Plasma was my original suspect.
Comment 14 Joe Da Silva 2020-12-31 22:15:01 CET
Perhaps adding XFCE added or edited something that was missing.
When you run "inxi -b" do you still have the same values as before?
Comment 15 Brian Kimerer 2021-01-01 00:58:51 CET
Plasma was not fixed when I installed XFCE. It still fails. It only works when I log into the XFCE desktop.

However......

On the Mageia forum Doktor5000 suggested that I set the back end of the compositor to XRender. I did that, and the transparency works again. I tried setting it to OpenGL3.1 instead of the default OpenGL2.0 and the transparency failed just as it did with OpenGL2.0.

I would like to understand what is going on here since I know very little about the software I am dealing with. So I will go off and study what I can find about the compositor code.

Anyway, a workaround for this problem is to use XRender as the compositor back end instead of the default OpenGL.

What is the policy for dealing with bugs that have a workaround? Do we close them?
Comment 16 Joe Da Silva 2021-01-01 07:04:28 CET
It fixes your problem "now"
but if you think it is something worth informing upstream with a link to this bug, it helps everyone else on a future release (regardless of if this bug is closed or remains open).
This might possibly be the closest: https://bugs.kde.org/show_bug.cgi?id=430874 from this list: https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&query_format=advanced&short_desc=background%20black&short_desc_type=allwordssubstr
but you'd have to test since it seems the rest of us can't replicate the bug.

...just my opinion.
Comment 17 Martin Whitaker 2021-01-01 11:12:38 CET
Interesting. I tried all three compositor backends when I tested it. Both XRender and OpenGL2.0 worked for me. With OpenGL3.1, even the Plasma desktop did not get displayed - it showed the startup splash screen and that was it.

If you are happy with the workaround, set the bug status to RESOLVED/WORKSFORME.
Comment 18 Brian Kimerer 2021-01-01 17:19:27 CET
I have read online that OpenGL3.1 is crashing kwin so the default backend is set to 2.0. On my system, the OpenGL3.1 setting worked the same as OpenGL2.0.

It does appear that my system may be unique with this bug since I have not seen a lot of "Me too" responses on the forum. However, until the upgrade on Dec 8 it was working fine, which implies that it is a system software problem.

I am going to go off and study compositors some more before posting upstream. I think I need to know more in order to post useful information. I can certainly test any proposed fix since this is my experimental system.

I don't see a RESOLVED/WORKSFORME in the dropdown menu, just RESOLVED. I am a newbie with Bugzilla; how would I set RESOLVED/WORKSFORME?
Comment 19 Aurelien Oudelet 2021-01-01 19:25:06 CET
(In reply to Brian Kimerer from comment #18)
> I have read online that OpenGL3.1 is crashing kwin so the default backend is
> set to 2.0. On my system, the OpenGL3.1 setting worked the same as OpenGL2.0.
> 
> It does appear that my system may be unique with this bug since I have not
> seen a lot of "Me too" responses on the forum. However, until the upgrade on
> Dec 8 it was working fine, which implies that it is a system software
> problem.
> 
> I am going to go off and study compositors some more before posting
> upstream. I think I need to know more in order to post useful information. I
> can certainly test any proposed fix since this is my experimental system.
> 
> I don't see a RESOLVED/WORKSFORME in the dropdown menu, just RESOLVED. I am
> a newbie with Bugzilla; how would I set RESOLVED/WORKSFORME?

So if compositor is set to XRender or to OpenGL 2.0, Plasma runs fine and transparency is OK?

If so, this can land in Release notes for Mageia 8.
Comment 20 Lewis Smith 2021-01-01 21:55:49 CET
Not quite; from comment 15:
> I set the back end of the compositor to XRender.
> I did that, and the transparency works again.
> I tried setting it to OpenGL3.1 instead of the default OpenGL2.0
> and the transparency failed just as it did with OpenGL2.0.
So, just XRender - I think.
Agree about the release notes. Noted.

I was unclear from c15 whether using XRender also fixed Plasma.
@Brian: can you clarify this?
And thank everybody for all your testing.

Keywords: 8beta2 => FOR_RELEASENOTES8

Comment 21 Brian Kimerer 2021-01-02 00:03:03 CET
Sorry for the confusion.

The transparency on Plasma works only when I set the compositor backend to XRender. Setting either of the OpenGL settings, 2.0 or 3.1, causes the transparency to fail on Plasma. 

The failure mode is a complete loss of translucent display on the desktop. For example, when I drag any window, it does not become translucent as I drag it. All of the apps that use transparent backgrounds have opaque backgrounds. My conky displays show black rectangles for backgrounds.

When I ran the XFCE DE, transparency worked with no changes to any settings. I do not know what window manager is used in XFCE. I didn't spend a lot of time looking into that DE.

I think that I will set the status of this ticket to RESOLVED since it is not a Mageia problem. I will look into posting a bug against kwin since it looks like a compositor problem, although I could just have a malfunctioning OpenGL stack. I don't know how to trouble shoot that yet.

Adding the workaround to the release notes sounds like a good idea.
Comment 22 Martin Whitaker 2021-01-02 11:09:43 CET
This would go in the errata, not the release notes.

But I don't think we've really got to the bottom of this. Brian is seeing the same failure with two different video drivers and two different OpenGL implementations.   That would seem to rule out a hardware-specific problem, particularly as I don't see the failure on a similar (slightly older) NVIDIA device. If the problem is in the Plasma compositor, I should see it too.

Brian, could you try using the 8-beta2 Live Plasma ISO. That was built on Dec 8th, so should contain the updates that broke your system. That would show if the bug is present in a clean install.

Keywords: FOR_RELEASENOTES8 => FOR_ERRATA8

Comment 23 Brian Kimerer 2021-01-02 14:30:24 CET
I will download 8-beta2 and put it on the computer. I might do this as a dual boot so as not to destroy what is there now for further investigation.
Comment 24 Martin Whitaker 2021-01-02 14:32:43 CET
That's why I suggested using the Live ISO - no need to install, just boot and test.
Comment 25 Brian Kimerer 2021-01-02 15:05:02 CET
Ah. OK. I missed that bit. I have downloaded the iso, so I will go boot it up and see what happens.
Comment 26 Brian Kimerer 2021-01-02 17:39:19 CET
I booted from the 8-beta2 live iso and all of the transparency works correctly out of the box. That was running the nouveau driver. I checked the kwin version, and it is 5.20.4-1, which is exactly the same version that was installed in the update that I ran on Dec 8. 

I could not try this with the nvidia driver installed because that would require a reboot, which sets it back to square one. If I put a persistence partition on the drive, can I install the nvidia driver to see what that does to it?
Comment 27 Martin Whitaker 2021-01-02 17:47:02 CET
If you select the second line in the boot menu:

  + use non-free NVIDIA drivers (slower to boot)

that should build and install the nvidia driver during boot.
Comment 28 Brian Kimerer 2021-01-02 20:15:58 CET
I should read the menus more carefully.

I booted with the Nvidia drivers, confirmed that the nvidia driver 340.108 is loaded in /var/log/Xorg.0.log and ran my apps.

The transparency effect works perfectly out of the box. So a fresh installation works fine. So something has been borked in my installed system to break it. 

This problem may be a random corner case that needs no action.

I initially installed mag8-alpha on the system and I have been doing the updates from cauldron. Could it be that the sequence of updates left something in a bad state and that would not be the case on a fresh install?

In any case, once mag8 released, the issue would not be there so the point is moot.
Comment 29 Brian Kimerer 2021-01-02 21:50:40 CET
Created attachment 12173 [details]
System Settings Compositor Warning Image

Screenshot of the compositor OpenGL warning in the Compositor Settings dialog.
Comment 30 Aurelien Oudelet 2021-01-02 21:56:21 CET
(In reply to Brian Kimerer from comment #29)
> Created attachment 12173 [details]
> System Settings Compositor Warning Image
> 
> Screenshot of the compositor OpenGL warning in the Compositor Settings
> dialog.

When KWin complains about bad drivers? Or OpenGL unstability, this is sometimes due to an other program that prevents Compositor to run well.

So, can you attach here the output as a text file:
$ rpm -qa > ./installed.rpm.txt

I will diff it with standard Plasma preset.
Comment 31 Brian Kimerer 2021-01-02 22:18:18 CET
I have apparently fixed the problem on the system now. 

I went back into System Settings => Display and Monitor => Conpositor to see if the problem still persists when using the OpenGL backends. I opened the dialog and selected the OpenGL 2.0 backend and sure enough, the transparency went away. Everything had black backgrounds.

However, when I opened the System Settings Compositor dialog box, it contained a warning in a purple box. I have uploaded a screenshot of the dialog box in the previous comment.

As shown in the attachment the warning says:

"OpenGL compositing (the default) has crashed KWin in the past.
This was most likely due to a driver bug.
If you think that you have meanwhile upgraded to a stable driver,
you can reset this protection but be aware that this might result in an immediate crash!
Alternatively, you might want to use the Xrender backend instead."

Then there is a button at the bottom that says

"Re-enable OpenGl detection" and a red X next to it.

Not knowing what any of that means, I had not clicked on that button in oder to avoid crashing  the system. So, this time I clicked the button and then reapplied the OpenGL 2.0 backend. The warning went away and the transparency started working again.

So my speculation in a previous comment that some sequence of events during upgrades seems to have broken the system seems to be the case.

Kwin somehow turned off its use of OpenGL at some point with a safety interlock and that affected the operation of the OpenGL backends WRT translucency? But it still let me choose OpenGL backends. They just didn't work anymore. 

So here is the situation... if you are cruising along with your system and all the transparency fails, you need to know that you need to open System Settings => Display and Monitor => Conpositor, read the dire warning about a possible error and click on the button that says "Re-enable OpenGl detection" despite the dire warning about crashing the system.

While this sort of makes sense to me now that I have dug into this, it seems as though it is not an obvious thing to do for a novice Plasma user.

Perhaps a note in the release notes or the errata about this would be in order?

Regardless, resetting the "protection" fixes the problem (if it doesn't cause an immediate crash).

I will post this outcome on the Forum as well so that it might at least show up in a search if it should happen to somebody in the future.

I think that this can be flagged as "RESOLVED" since the exact same sequence of crashes and error checks and interlock triggers are unlikely to occur on another system to cause this.

What do you think?
Comment 32 Lewis Smith 2021-01-02 22:26:30 CET
(In reply to Martin Whitaker from comment #22)
> But I don't think we've really got to the bottom of this. Brian is seeing
> the same failure with two different video drivers and two different OpenGL
> implementations.   That would seem to rule out a hardware-specific problem,
> particularly as I don't see the failure on a similar (slightly older) NVIDIA
> device. If the problem is in the Plasma compositor, I should see it too.
I agree with all this, although I did not spot it & have no 'control' to play with.
Brian's further tests as suggested by Martin are encouraging (fault NOT present) for new installs - though they should survive a subsequent update. With the fact that XRender does the trick for Brian, I think this can be closed - but bow to greater wisdom.

As for ERRATA, is this still an issue? I think not (to clear).
Comment 33 Brian Kimerer 2021-01-02 23:04:14 CET
Created attachment 12176 [details]
Installed Packages

I have attached the requested list of installed rpm's.
Comment 34 Brian Kimerer 2021-01-02 23:17:20 CET
I suspect that the chances of anyone else running into this problem after an update would be very slim. It is not a bug in the software. It is the result of interlocks being triggered from some oddball event on this particular computer.

I do not think that it belongs in ERRATA because it really is not an error.

What kept me chasing ghosts for these last few days was simply not knowing where to look to fix the situation. A "fix" for this would involve having an easier way to figure out what is going on, but I don't know how that would be done.

I doubt I will ever be able to discover what exactly happened to cause the Compositor to lock out OpenGL like that. Stuff happens. 

As I said in a previous comment, I will post this resolution on the Forum on the thread that I started about this issue. That way, if it does crop up on somebody else's system, they might find the resolution in a search.

Given the low probability of it happening again, I think that a notice in the release docs isn't required. Anybody else think differently?

BTW, Thanks to everybody for helping me look into this.
Comment 35 Brian Kimerer 2021-01-03 03:08:23 CET
I am marking this RESOLVED since the actual cause of the effect was the lockout from OpenGL by the Compositor, and I have fixed that by resetting the protection that was being provided by the interlock. There are no upstream bugs to report.

Resolution: (none) => FIXED
Status: UNCONFIRMED => RESOLVED

Comment 36 Morgan Leijström 2021-02-06 12:57:03 CET
This bug still have FOR_ERRATA8 set.

Should we write something (what?), or did the fix make it into released RC?

CC: (none) => fri

Comment 37 Martin Whitaker 2021-02-06 13:25:38 CET
I agree with Brian in comment 34 - this doesn't belong in the Errata because it is not really an error. Plasma is behaving as its designers intended. If it fails to start with compositing enabled, it silently disables compositing and tries again. But it never automatically re-enables compositing, and unless you go looking in system settings, you don't know that it has done this.

We can't document every quirk of every bit of software we package in the Errata. That sort of thing belongs on the Wiki or in the Tips and Tricks section of the forum.

Keywords: FOR_ERRATA8 => (none)


Note You need to log in before you can comment on or make changes to this bug.