Created attachment 133831 [details] Gwenview transparency SUMMARY I'm not even sure where to post this, but I'm having major GUI issues with this update (Previous update on 2020-10-25) STEPS TO REPRODUCE 1. Update Arch Linux 2. Open an image in gwenview OBSERVED RESULT No image is displayed, but rather the viewbox for the image is transparent. EXPECTED RESULT Display the image SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION This isn't just about gwenview. My first encounter with something wrong was when I ran kodi that I had to rebuild because of the update. When I ran kodi, any mouse click on the window buttons were passed through to whatever was layered beneath the buttons (example: if I had this browser maximized and kodi was located at the top right corner over the browser window, and I click the close button in kodi, kodi remains open but the browser would close). I was going to submit a bug to kodi about that, but something felt off. When I was doing other stuff, I noticed issues with right-mouse clicking things might take multiple clicks before any context menu would come up. In addition, if I right-mouse on an open program on the bottom panel and the moment I hover over a menu item with children, the main context menu disappears while the child remains. But even then, trying to move that program to another activity (child menu item) doesn't happen. Everything is so horribly messed up that I'm exploring what it takes to rollback. Hopefully you can get back to me before I do that so I can do whatever you need me to look into/try. In case you're thinking "compositor", I have it set to "XRender".
I think it may be wayland. I'm looking into it. Not sure if that's something new that KDE now loads into it automatically. Wayland has always been horrible for me and I avoid it like the plague.
Yeah, it was wayland. For whatever reason that was the default at login. It is not something I chose. I logged out, switched to "regular" Plasma, but logging back in was taking awhile so I opened another tty and just rebooted (saw a coredump was happening on reboot). When it got back to sddm, wayland was still the default (don't know if it will always be that way now or "regular" didn't set/commit because login didn't complete. I don't know if this should just be closed or moved to a wayland-related "product".
I can reproduce this with: - Gwenview 20.122. - Plasma 5.20.3 - Wayland session - Qt 5.15.2 - Mesa 21.0.0 (Intel) - Fedora 34 (beta) Gwenview spews a bunch of errors: QWaylandShmBuffer: mmap failed (Invalid argument) QWaylandShmBuffer: mmap failed (Invalid argument) QWaylandShmBuffer: mmap failed (Invalid argument)
mmap() can fail with EINVAL in the following cases EINVAL We don't like addr, length, or offset (e.g., they are too large, or not aligned on a page boundary). EINVAL (since Linux 2.6.12) length was 0. EINVAL flags contained none of MAP_PRIVATE, MAP_SHARED, or MAP_SHARED_VALIDATE. The relevant code in qwaylandshmbackingstore.cpp uchar *data = (uchar *) mmap(nullptr, alloc, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); so, it's most likely that the specified length is either 0 or it exceeds the limits. It's hard to say without being able to reproduce the bug.
kstars can also run into this mmap() error: https://bugs.kde.org/show_bug.cgi?id=430325#c1
Heads up: I'm proposing this bug as a blocker for the Plasma Wayland session by default in Fedora 34: https://bugzilla.redhat.com/show_bug.cgi?id=1949821 Fedora 34 is scheduled to release in just 5 days, so it might be too late to land a fix in the release media at this point, but there's still hope to get it out as a "zero day" update.
The SHM thing is probably unrelated. We should have just the one window with one buffer and we can see all the toolbars and such drawing correctly so we know in general that's working. The fact that this fills only the image view area implies it's using gwenview's GL backend which had a bug. @bernie can you confirm (settings -> image view -> animations) I was under the impression this was fixed: https://bugs.kde.org/show_bug.cgi?id=403323
Yes, I had Animations set to OpenGL. Resetting Animations to the default (Software) fixed the transparency issue, but caused another rendering bug (see attached screenshot). Tested with Gwenview 20.12.2 running in Wayland on Fedora 34.
Created attachment 137630 [details] Rendering bug with Animations set to Software
I cannot reproduce the above bug after restarting Gwenview. It only happens if: 1. Configure Animations: OpenGL 2. Open a directory (e.g. the Desktop folder) 3. Go to settings and switch to Animations: Software 4. Click on an image 5. The frame around the image isn't cleared to black, and continues to show the desktop This is a minor issue, but I could file this as a separate bug if desired.
Given we know you had a relatively old gewnview there's a chance that's fixed by https://invent.kde.org/graphics/gwenview/-/commit/955df5addac77b49c8349e6477806dbf27bde238
All of those fixes landed in Gwenview 21.04; could you check again once it's released in one week? Arch packaging is usually super fast. Thanks!
> All of those fixes landed in Gwenview 21.04; could you check again once it's released in one week? > Arch packaging is usually super fast. Thanks! I can only reproduce this bug on my laptop (Fedora 34 with Intel graphics). I also tested on my desktop (Arch with amdgpu and KDE built from git). Gwenview works fine there, both 21.07.70 and the 20.12.3 binary packaged by Arch. Closing as fixed, I have already filed a bug on Fedora to update their Gwenview package.