Created attachment 135273 [details] Context Menu entries disappearing SUMMARY Wayland context Menus entries disappear/ graphic glitching Works fine on Xorg! STEPS TO REPRODUCE 1. rightclick on desktop 2. move mouse above entries 3. OBSERVED RESULT Weird diasppearing of entries (see attachment) EXPECTED RESULT steady displaying all entries SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.20.90 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.10-arch1-1 OS Type: 64-bit Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor Memory: 15.5 GiB of RAM Graphics Processor: Radeon RX 580 Series
Created attachment 135631 [details] plasma wayland menu glitching Same issue here. It only occurs on scaled displays (100% is fine, attached video shows glitching at 200%). It seems the menu is first drawn blurry. As soon as the mouse pointer enters the menu-item below the cursor is drawn crisp, but not the whole menu. Operating System: EndeavourOS KDE Plasma Version: 5.20.90 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.15-zen1-1-zen Graphics Processor: Radeon RX 5500 XT
Do you have several outputs with different scale factors?
I can reproduce it if one of my outputs have a scale factor of 1. This looks like a QtWaylandClient issue though.
Yeah i have the same with different scale factors. I have 3 screens 2 with scale factor 1 1 with scale factor 1.75 it happens on all screens.
(In reply to Vlad Zahorodnii from comment #3) > I can reproduce it if one of my outputs have a scale factor of 1. This looks > like a QtWaylandClient issue though. Yes, I have multiple monitors with different scale factors incl. 1, too. Do you still need an example with different scale factors?
(In reply to openmail+kde from comment #5) > Do you still need an example with different scale factors? No, thanks
I have seen it as well.
*** Bug 449827 has been marked as a duplicate of this bug. ***
*** Bug 446563 has been marked as a duplicate of this bug. ***
*** Bug 450207 has been marked as a duplicate of this bug. ***
Created attachment 146764 [details] Screenshot: OBS Studio 27.1.3 on openSUSE TW with Plasma 5.24.0 I see something similar for the dialogs in OBS Studio 27.1.3 (with and without export QT_QPA_PLATFORM=wayland), where parts of the dialogs (background, buttons, ...) are missing but do return partly on mouse hover. Do you think it's the same cause? System: openSUSE TW, Plasma 5.24.0
One additional note to comment 11: The issue with OBS does not happen with scaling 1.0 but with 2.0, just as described in comment 1. So I guess it has the same root.
Small update from me. Today I found out that when I open the context menu and then press left alt (as for using hints etc) the context menu gets redrawn (?) to make it all solid as expected. Example: https://youtu.be/qJI0ezn-91Y Hope this helps to point devs into right direction.
*** Bug 451061 has been marked as a duplicate of this bug. ***
*** Bug 451235 has been marked as a duplicate of this bug. ***
I wanted to add some more weird but related behaviour I saw. So my laptop screen is at 125% scaling and the (only) external screen is at the default 100%. The context menu bugginess happens only on the screen which is either towards the right or below the "first" screen. To elaborate, I had two different setups of the displays. First, the monitor next to laptop. In this case, only the display on the right side had the flickering. In the second case, I put the monitor "above" the laptop in the display settings and then only the laptop screen (which was on the bottom) had the flickering
(In reply to airmailsteam from comment #16) > I wanted to add some more weird but related behaviour I saw. So my laptop > screen is at 125% scaling and the (only) external screen is at the default > 100%. The context menu bugginess happens only on the screen which is either > towards the right or below the "first" screen. > > To elaborate, I had two different setups of the displays. First, the monitor > next to laptop. In this case, only the display on the right side had the > flickering. In the second case, I put the monitor "above" the laptop in the > display settings and then only the laptop screen (which was on the bottom) > had the flickering I am using Arch with KDE plasma 5.24.4 as of now. I dont have nvidia gpu
I can confirm this bug seems to be fixed in the fedora 36 release version.
(In reply to zerx from comment #18) > I can confirm this bug seems to be fixed in the fedora 36 release version. I am sorry, I commented too fast. I don't know how to delete/edit it. Sadly the bug is still present on the unscaled display.
I can reproduce it - when having two outptus it only happens on the right output no matter which one is scaled - on open it appears blurry and as soon as I move the mouse transparent areas appear.
I think that wayland log fits that https://invent.kde.org/-/snippets/2194
Created attachment 148949 [details] partially rendered QT6 widgets I noticed what might be related in *every* QT 6 app (in this case qBittorrent with QT 6.3 libs): Dialogs are also partially rendered blank, individual widgets are rendered on hover or if the dialog is resized. Only happens on the monitor which also shows the partially rendered menu. Does somebody with a broken menu see the same behavior or should this go into a new bug? Operating System: EndeavourOS KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Kernel Version: 5.17.8-zen1-1-zen (64-bit) Graphics Platform: Wayland
(In reply to Schlaefer from comment #22) > Created attachment 148949 [details] > partially rendered QT6 widgets > > I noticed what might be related in *every* QT 6 app (in this case > qBittorrent with QT 6.3 libs): > > Dialogs are also partially rendered blank, individual widgets are rendered > on hover or if the dialog is resized. Only happens on the monitor which also > shows the partially rendered menu. Can at least confirm that eg with Strawberry compiled against Qt 6.3.0.
Just noticed that I * _do not_ see this glitch at all if both of my two screens are scaled 2x * _do_ see this glitch if one screen is scaled 1x and the other 2x
Another observation on Plasma 5.24.5 (Tumbleweed): Open either VLC (3.0.17, Qt5?) or Strawberry (Qt 6.3.0) or OBS (27.2.4) so that they have a tray icon in the system tray. The first time you open the context menu of the tray icon, it looks broken as described in this bug report. From the second time on you open it, it keeps however looking absolutely fine.
*** Bug 454691 has been marked as a duplicate of this bug. ***
I made the following observations with left A: 1920x1080 screen right B: 3840x2160 screen (primary) on Plasma 5.25.2 Wayland Scaling of A / B: 100 / 200: issue either on A or B (*) 125 / 200: fine 150 / 200: fine 175 / 200: fine 200 / 200: fine 225 / 200: issue either on A or B (*) 250 / 200: issue either on A or B (*) 275 / 200: issue either on A or B (*) 300 / 200: issue either on A or B (*) (*): Whether the issue appears either on A or B depends on how they are positioned relative to each other vertically, given that A's right edge touches B's left edge. If A is roughly positioned at (0, x) with x <= ~475 the issue happens on right primary screen "B", else if it is lower, x >= ~481 the issue appears on the left screen "A".
Note to comment 27: I made the same observation for a different bug. [1] [1] https://bugs.kde.org/show_bug.cgi?id=455415#c4
I am having this issue with a central 4k monitor scaled up to 200%, and two other non 4k monitors at native resolution.
I can confirm I've had this same issue for a year now and across multiple distros. I first noticed it in Manjaro when switching to wayland and it happens all over the place. I switched to arch recently and the same issue persists with the exception of dolphin, where the context menu acts normally. I'm pretty sure I also encountered the same bug on fedora 36 when I last tried it, but my memory is a little fuzzy on that now. As for monitors I'm running, the configs are... 3840x2160 @ 165% scaling -- 60hz, rotated 90° 2160x1440 @ 100% scaling -- 165hz, primary
Created attachment 151670 [details] bug in latest arch, 2022-08-27
I notice that if I scale my second monitor to 1.01 (main monitor scale is 1.25) this stops happening, it still happens with the second monitor scaled at 0.99 tho (kscreen-doctor output.2.scale.1,01)
I have exactly the same issue, with the left-monitoring working fine on 125%, the right-monitor on 100% fails to render the popup menus properly. My setup, the right-monitor is the primary monitor, so AFAIK it has nothing to do with primary/secondary, but with the position of the monitor. If I swap left to right, and keep the primary monitor the same as it was (so it becomes left), then the 125% monitor fails rendering the popup menus.
FYI: Here is the upstream issue that i found: https://bugreports.qt.io/browse/QTBUG-103348 Apparently this seems to be closed, so it would be nice if we could get some status update on this. After all, the issue exists for almost two years now.
From what I remember when I invesigated this, this is Qt bug, the screen of the menu is changed/set by QWidgets without notifiyng the QPA, so a later screen change by the QPA noops.
This sounds like https://bugreports.qt.io/browse/QTBUG-93380, I suspect Qt may missing requestUpdate when scaling is in use, they had the same issue with CSD (https://bugreports.qt.io/browse/QTBUG-95032) that got fixed with an additional requestUpdate call in CSD-related code, but I guess this was not a right fix fixing the problem when CSD is in use leaving non-CSD windows bugged.
Created attachment 154814 [details] Request update patch Can someone test whether this qtwayland patch fixes the problem?
Created attachment 154815 [details] Request update patch v2 Oops, it should be QWindow::requestUpdate, not QPlatformWindow::requestUpdate
(In reply to Ilya Fedin from comment #38) > Request update patch v2 Don't see any difference after the patch. Menus and windows are still bugged.
Created attachment 154928 [details] Request update patch v3 Added the same changes to EGL buffer integration that is used by QML
(In reply to Ilya Fedin from comment #40) > Created attachment 154928 [details] > Request update patch v3 > > Added the same changes to EGL buffer integration that is used by QML I manually applied the patch to the latest qt5-wayland package on Arch Linux (5.15.7-lts-lgpl). It would be good to know which version or git commit you patched against. This is better, but the context menu flashes once when you initially start to move down the menu. Light blue lines appear and disappear intermittently between the menu items as I move my mouse up and down the menu. Thank you! My setup: 2560x1440@120Hz (100% Scaling) + 3840x2160@60Hz (150% Scaling) with Mesa driver. Issue occurs on the 4K monitor with the scaling. KDE Plasma: 5.26.4 KDE Frameworks: 5.101.0 QT: 5.15.7 Kernel Version: 6.1.1-arch1-1 Graphics Processor: AMD Radeon 6700 XT
(In reply to Ilya Fedin from comment #40) > Created attachment 154928 [details] > Request update patch v3 There's clearly an improvement in v3 here too. Menus still start somewhat blurry at first (maybe a different issue) but seem to get redrawn once and are fine. QT6 subviews are still drawn incomplete. Short videos to show the change: https://nextcloud03.webo.cloud/s/ZrFMZYXgpP3DDzM Operating System: EndeavourOS KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.1.1-zen1-1.1-zen (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon RX 5500 XT
I guess it's blurry because Qt thinks the menu is on a monitor with lower scale. The fact qBittorrent still shows black square in way more interesting though, I wonder why the (CPU-based) backing store still doesn't do full repaint.
Created attachment 154954 [details] Request update patch (Qt 6) Ah, you say qbittorrent is built with Qt 6. Here's the variant for Qt 6 (based on v6.4.1).
Created attachment 154955 [details] Arch patched v3 QT6 video (In reply to Ilya Fedin from comment #44) > Created attachment 154954 [details] > Request update patch (Qt 6) > > Ah, you say qbittorrent is built with Qt 6. Here's the variant for Qt 6 > (based on v6.4.1). Yes. Blacked out/blank dialog areas are a QT6 only issue. This version behaves the same as the previous v3. qBittorrent preferences saw the same slight improvement. Since it is already running I also recorded an obs QT6 dialog, which looks exactly the same patched and unpatched.
Created attachment 154956 [details] Arch patched v3 QT6 correct (In reply to Schlaefer from comment #45) > Since it is already running I also recorded > an obs QT6 dialog, which looks exactly the same patched and unpatched. Scratch that, that OBS was flatpak and therefore ran unpatched. This attachement is qBittorrent *and* OBS patched. Both show the same improvement: the outer most area is drawn correctly now, but not the subview.
Ah, you were applying the previous patch to the Qt 6? Yeah, it's the same, just made on top of Qt 6 tree.
(In reply to Ilya Fedin from comment #47) > Ah, you were applying the previous patch to the Qt 6? Yeah, it's the same, > just made on top of Qt 6 tree. Ah OK. To be clear, Arch offers separate qt5-wayland [1] and a qt6-wayland [2] packages, since the patch is only a few lines I applied them manually onto them (the original v3 on both and the last, dedicated QT6 on qt6-wayland). [1] https://archlinux.org/packages/extra/x86_64/qt5-wayland/ [2] https://archlinux.org/packages/extra/x86_64/qt6-wayland/ PS: I'm just happy that someone looks into the issue, so I don't mind a little bit of manual work. ;)
*** Bug 463954 has been marked as a duplicate of this bug. ***
*** Bug 464702 has been marked as a duplicate of this bug. ***
*** Bug 465190 has been marked as a duplicate of this bug. ***
*** Bug 466753 has been marked as a duplicate of this bug. ***
*** Bug 467203 has been marked as a duplicate of this bug. ***
*** Bug 468000 has been marked as a duplicate of this bug. ***
*** Bug 468724 has been marked as a duplicate of this bug. ***
(In reply to Schlaefer from comment #42) > There's clearly an improvement in v3 here too. Menus still start somewhat > blurry at first (maybe a different issue) but seem to get redrawn once and > are fine. I'm experiencing this for a while and just opened a report today (Bug 468725). There did not seem to be any other reports of this. Initially it was all menus, but now it's only submenus. Indeed it seems like "redraw" fixes the blur now. No idea why partially fixed... The context menu bug also seems to be related to "redraw". Might have some link, though I'm not sure.
*** Bug 448409 has been marked as a duplicate of this bug. ***
*** Bug 473524 has been marked as a duplicate of this bug. ***
*** Bug 473936 has been marked as a duplicate of this bug. ***
*** Bug 474229 has been marked as a duplicate of this bug. ***
*** Bug 474597 has been marked as a duplicate of this bug. ***
Is this tracked upstream in Qt somewhere, especially for Qt 5? I don't see any activity in the bugs that were linked... Maybe Nate can file another bug or ping them?
(In reply to Asahi Lina from comment #62) > Is this tracked upstream in Qt somewhere, especially for Qt 5? I don't see > any activity in the bugs that were linked... Maybe Nate can file another bug > or ping them? This bug is fixed in Qt 6.6
(In reply to indx from comment #63) > (In reply to Asahi Lina from comment #62) > > Is this tracked upstream in Qt somewhere, especially for Qt 5? I don't see > > any activity in the bugs that were linked... Maybe Nate can file another bug > > or ping them? > > This bug is fixed in Qt 6.6 But not backported to Qt 5...
That's right, it's not. :) Unfortunately not every Qt 6 change is feasible to backport to the KDE Qt5 patch collection.
> That's right, it's not. :) Unfortunately not every Qt 6 change is feasible > to backport to the KDE Qt5 patch collection. That's kind of unfortunate... this bug is pretty ugly for anyone using multi-screen with different scales on Wayland, which is one of the things Wayland is supposed to be good at ^^;;
yeah I am really wondering. I dont care about stable releases and will happily switch to Plasma 6, but what about Debian and Kubuntu? Will they just keep the broken versions forever? I understand backporting is annoying and duplicate work.
(In reply to Henning from comment #67) > yeah I am really wondering. I dont care about stable releases and will > happily switch to Plasma 6, but what about Debian and Kubuntu? Will they > just keep the broken versions forever? > > I understand backporting is annoying and duplicate work. Both should eventually get Plasma 6, but it will be potentially months (for Kubuntu) or years (for Debian) after being released by KDE. But that's what you're signing up for when you use distros like Debian and Kubuntu. In the context of those distros, "stable" doesn't mean "lack of bugs", it means "the bugs don't change--either old ones being fixed, or new ones appearing."
*** Bug 479392 has been marked as a duplicate of this bug. ***
So this will just never be fixed for plasma 5? lmao
Kubuntu will not ship Plasma 6 in its new release. I heard there are some additional devs, this seems like these people should deal with that issue 🤷🏾
(In reply to Henning from comment #71) > Kubuntu will not ship Plasma 6 in its new release. I heard there are some > additional devs, this seems like these people should deal with that issue > 🤷🏾 Well, knowing it is fixed in a next major dependency version, that's a very advanced topic (a fix in qtwayland is required), that the package that should receive the fix is not even maintained by the Kubuntu dev team, incentive is very low to engage resources to fix this bug as it is not critical (concerns only users with 2+ screens in certain cases) when at the same time kubuntu has no devs involved in Wayland support AFAICT and very few in the first place. Kubuntu devs have plenty to do be able to ship Plasma 6, KF6 and Gear 6 already, plus the ubuntu one effort... This is annoying like any bug, I feel the pain myself, but I am afraid you will have to live with it for a few more months. Please be mindful about your expectations.