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
Could this be another manifestation of Bug 27884 ?
CC: (none) => lewyssmith
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
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.
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.
Maybe try Xorg-vesa - there is also generic VESA this would exclude the nvidia and any other possible GPU magic
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) => ouaurelienEver confirmed: 1 => 0Status: NEW => UNCONFIRMED
Source RPM: (none) => nvidia340-340.108-15.mga8.nonfree.src.rpmKeywords: (none) => 8beta2Summary: Transparency No Longer Works in Qt Applications => nvidia graphic card needing nvidia340 nonfree driver can't have transparency work in Qt Applications
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.
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.
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).
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
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.
Neither IceWM nor LXDE enable a compositor by default, which I think is why they don't support transparency.
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.
Perhaps adding XFCE added or edited something that was missing. When you run "inxi -b" do you still have the same values as before?
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?
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.
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.
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?
(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.
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
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.
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
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.
That's why I suggested using the Live ISO - no need to install, just boot and test.
Ah. OK. I missed that bit. I have downloaded the iso, so I will go boot it up and see what happens.
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?
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.
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.
Created attachment 12173 [details] System Settings Compositor Warning Image Screenshot of the compositor OpenGL warning in the Compositor Settings dialog.
(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.
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?
(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).
Created attachment 12176 [details] Installed Packages I have attached the requested list of installed rpm's.
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.
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) => FIXEDStatus: UNCONFIRMED => RESOLVED
This bug still have FOR_ERRATA8 set. Should we write something (what?), or did the fix make it into released RC?
CC: (none) => fri
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)