SUMMARY I'm having context menu misbehave in my current mixed DPI setup. When a 4K display (28", display 1, HDMI) has any scale applied and QHD display (27", display 2, DisplayPort) has no scale applied, the context menus of Plasma are not showing everything when opened, and show contents on mouse hover. I've played around with different settings and I was almost convinced that this will happen on a non-scaled display only. But after I tried the reverse (no scale on display 1, scale on display 2) I still got this issue on display 2, but not on display 1. STEPS TO REPRODUCE 1. Scale display 1 to 200% 2. Scale display 2 to 100% (no scaling) 3. Try context menu on display 2 - will misbehave 1. Scale display 1 to 100% (no scaling) 2. Scale display 2 to 100% (no scaling) 3. Try context menu on either display - all will work correctly 1. Scale display 1 to 200% 2. Scale display 2 to 200% (or 150, 175% - any scale other than 100%) 3. Try context menu on either display - all will work correctly 1. Scale display 1 to 100% (no scaling) 2. Scale display 2 to 125% (or 150, etc.) 3. Try context menu on display 2 - will misbehave OBSERVED RESULT Context menu of plasmashell (on widgets, on desktop) flickers and redraws on mouse hover. Demonstration: https://youtu.be/--c3om5X3uE Left screen is scaled 175%, same for 200%. Right is not scaled (100%). Dolphin on right display - context menu is OK. Applets and desktop context menu are being redrawn (?) and mostly incomplete on the right screen. EXPECTED RESULT Context menu behaves as on the left screen. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux with Plasma 5.23.4 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 GPU: AMD RX 550 / open source drivers ADDITIONAL INFORMATION Turing bless Plasma Wayland session. It's come a long way since I was first trying it in 2017. Still some work to do, but right now I'm easily daily driving it for a week or so.
Same here. Been like this for a while, months at least. Amdgpu driver here too, one 1080p monitor and one 4m on 200% scale. RX 6800 gpu
I should add, if you rearrange the display layout so that the monitor where everything is fine is on the right, the bug occurs on the other monitor (the 200% scaled one). I should also add, if I scale the monitor to 101%, the issue disappears. (But that's obviously not a proper solution).
(In reply to justinkb from comment #2) > I should add, if you rearrange the display layout so that the monitor where > everything is fine is on the right, the bug occurs on the other monitor (the > 200% scaled one). Yup, I can observe the same thing. I've rearranged my desk since submitting this bug and... Now I can say that the context menu is broken on the right display that is scaled 200%. If I virtually rearrange them so that the scaled one is back on the left - the issue is gone. This might be connected with something else I just noticed. If I drag any KDE app (i.e. KScreen KCM, Dolphin etc., so might be Qt thing...) to non-scaled display and back to scaled one - scaling doesn't work. If I flip my displays to be on opposite sides - scaling works when dragging across. I will submit a separate bug report later today. But I get a feeling that these are connected.
(In reply to Szymon Łągiewka from comment #3) > If I drag any KDE app Forgot to mention - this doesn't happen to Electron apps with Ozone and Firefox running in native Wayland. They rescale normally.
Known Qt bug. Can you report this issue to Qt developers? https://bugreports.qt.io/
not sure why you thought this was a proper way to handle this bug report, kicking the can down the road, even tho kde maintains a big patch set for qt? this makes kde unusable for me, so I just use another DE. i'm not gonna do your job and chase down this bug you claim is in qt.
If you think that we're obliged anything or that you're free to lash out at open source developers like that, that's not how open source works. --- That being said, it looks like this issue is already reported in our bugzilla, so marking as a duplicate. *** This bug has been marked as a duplicate of bug 432264 ***
if your bar for "lashing out" is so low my comment cleared it, might wanna hang it a bit higher. it's amusing you're again just kicking the can for someone else to solve the issue, though, by marking it as a duplicate of a year old bug report you can clearly see hasn't had any progress for the entire time since being reported. (In reply to Vlad Zahorodnii from comment #7) > If you think that we're obliged anything or that you're free to lash out at > open source developers like that, that's not how open source works. > > --- > > That being said, it looks like this issue is already reported in our > bugzilla, so marking as a duplicate. > > *** This bug has been marked as a duplicate of bug 432264 ***
(In reply to justinkb from comment #8) > if your bar for "lashing out" is so low my comment cleared it, might wanna > hang it a bit higher. > > it's amusing you're again just kicking the can for someone else to solve the > issue, though, by marking it as a duplicate of a year old bug report you can I don't know why you think that we (kwin developers) are obliged to fix client side bugs. Being rude won't help with anything :/
I think you are getting a bit confused about things. Kwin is a Qt wayland api consumer. If Kwin users are experiencing bugs with Kwin due to Qt wayland client code being buggy, it's in your interest and falls within your responsibility as Kwin developer to at least get in touch with Qt developers about the issue and raise it on their bug tracker. You shouldn't be delegating that to your users, but take action yourself. I'm kind of baffled you haven't done so in the year time since that initial bug got reported, but I guess you failed (and have kept failing) to understand that is in fact part of your responsibilities.