KDE applications do not popup menus unless in non scaled display.

[evilbulgarian]

• Sway Version: sway version 1.4

• Debug Log: https://bpaste.net/MIJQ

• Configuration File: https://bpaste.net/2NWQ

Hi, I have3 displays configured one with display scale of 1.5 I am unable to see menu's on kde-apps applications. If I remove my external displays from my sway configuration and just leave my laptop display with a 1.5 scale on it works fine https://bpaste.net/OQBQ. Also if I have my external monitors plugged in and open the kde app on one of them the menus also display fine. Finally, explain the steps you took in plain English to reproduce the problem below.

[ghost]

Same problem here. It's related to Qt application like Wireshark.

Screen configuration when i have problem : Laptop screen(FHD) disabled no scaling External screen(4K) enabled scaling x2

If I just enable my laptop screen, it'll work again.

[Xyene]

The logs have disappeared (404), please re-upload them to https://gist.github.com/, or somewhere similarly more permanent. If possible, also try the latest sway/wlroots master, as the issue may have been fixed since then. Lastly, is this issue regarding Qt running through Xwayland, or through Qt's Wayland backend (QT_QPA_PLATFORM=wayland)?

[Thanson16]

I am experiencing what I believe to be the same issue, but I think I can provide a little bit more nuance to what is happening:

My setup is a laptop in clamshell mode with two external displays attached. The monitors are "laid out" horizontally in my config like so:

[laptop] [monitor 1] [monitor 2]

All are 1920x1080 with no scaling applied.

When the laptop is open, all behaves normally. However, when clamshell mode is activated, KDE menus (such as those in Okular) do appear. However, they are shifted to the right one full monitor's worth. Hence, if the application is on the rightmost monitor, the menu doesn't appear at all. If the application is open on monitor 1, the menu pops up over on monitor 2.

So, what appears to be happening is the menu is being shifted as if the laptop is open, even though that monitor is deactivated (clamshell mode).

Hence, it doesn't seem to be a scaling issue, but almost like a "monitor offset" issue.

Hope this helps.

I can help provide more info later if you guys want; might be busy for a couple days though.

I'm using the latest Sway in the Arch repos; 1.4, and using QT_QPA_PLATFORM=wayland.

[tmccombs]

I believe I am also seeing the same problem, and can add more information on reproducing.

I have output configuration like this:

output $left_screen pos 0 100
output $right_screen pos 1920 0

If I open a menu in a qt application on the left screen, the menu appears to open 100 pixels lower than it should, and if I open it on the right screen the menu doesn't appear at all. I believe the menu may be shifted over by the offset of the screen. This is confirmed by the fact that if I change the pos of the left screen to "0 0" the menu appears where it should, and if I change it to "0 300" it is even more offset. And I can add a horizontal offset by changing the position to "100 100".

I see this in multiple QT apps, including okular and wireshark. I also don't see this behavior in weston, so it seems sway, or wlroots specific.

Here's a debug log: https://gist.github.com/tmccombs/15b97b7d3d448ec9fcaa4a7429102856

I'm happy to provide more information if needed.

[tmccombs]

I found something suspicious. sway seems to set the x and y positions in the wl_output gemoetry to 0 regardless of the monitor offset.

weston, however, sets the x value of the wl_output.geometry to the same value as the x value in the logical position.

sway:

[1861905.360] [email protected](0, 0, 520, 320, 2, "Ancor Communications Inc", "VS24A", 0)
[1861905.393] [email protected](1, 1920, 1200, 59950)
[1861905.411] [email protected](1)
[1861905.418] [email protected]()
[1861905.430] [email protected]("DVI-I-1")
[1861905.438] [email protected]("Ancor Communications Inc VS24A E7LMQS031673 (DVI-I-1)")
[1861905.446] [email protected]_position(1920, 0)
[1861905.457] [email protected]_size(1920, 1200)
[1861905.468] [email protected]()

weston:

[3638404.613] [email protected](1920, 0, 520, 320, 2, "ACI", "VS24A", 0)
[3638404.646] [email protected](1)
[3638404.653] [email protected](3, 1920, 1200, 59950)
[3638404.671] [email protected](0, 1920, 1080, 60000)
[3638404.688] [email protected](0, 1600, 1200, 60000)
[3638404.706] [email protected](0, 1680, 1050, 59883)
[3638404.723] [email protected](0, 1280, 1024, 60020)
[3638404.741] [email protected](0, 1440, 900, 59901)
[3638404.758] [email protected](0, 1280, 960, 60000)
[3638404.776] [email protected](0, 1024, 768, 60004)
[3638404.793] [email protected](0, 800, 600, 60317)
[3638404.811] [email protected](0, 800, 600, 56250)
[3638404.828] [email protected](0, 640, 480, 59940)
[3638404.846] [email protected]()
[3638404.851] [email protected]_position(1920, 0)
[3638404.861] [email protected]_size(1920, 1200)
[3638404.872] [email protected]("DVI-I-1")
[3638404.880] [email protected]()

It does seem weird that that would make a difference though. And looking at the code for creating a popup, it isn't obvious to me why that would make a difference.

It definitely does seem like a bug that the reported geometry doesn't include the offset though.

[emersion]

sway seems to set the x and y positions in the wl_output gemoetry to 0 regardless of the monitor offset

This is by design. Regular apps shouldn't care about it.

[tmccombs]

This is by design. Regular apps shouldn't care about it.

I agree, and I'm not 100% sure this is what is causing it, although it is suspicious.

p.s. it would have been nice to link to https://github.com/swaywm/wlroots/issues/1610 to give more context on what you meant by "This is by design".

[tmccombs]

I created a bug with qt: https://bugreports.qt.io/browse/QTBUG-85297

[OctopusET]

If you use arch-based distro, patch for this bug has backported to qt5-wayland package. https://github.com/archlinux/svntogit-packages/commit/e021ace4f98f9855c5b47e9451771c563fc05373