Bug 430524 - Windows and Kickoff / KRunner opens in the wrong monitor
Summary: Windows and Kickoff / KRunner opens in the wrong monitor
Status: RESOLVED DUPLICATE of bug 379475
Alias: None
Product: plasmashell
Classification: Plasma
Component: generic-multiscreen (other bugs)
Version First Reported In: master
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Aleix Pol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-18 06:23 UTC by David Rubio
Modified: 2021-08-17 01:50 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
qdbus org.kde.KWin /KWin supportInformation (6.62 KB, text/plain)
2020-12-18 06:23 UTC, David Rubio
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Rubio 2020-12-18 06:23:43 UTC
Created attachment 134167 [details]
qdbus org.kde.KWin /KWin supportInformation

SUMMARY
Windows and Kickoff / KRunner opens in the wrong monitor under Wayland. This does NOT happen on X11. I have two monitors: HDMI-A-1, and HDMI-A-2, in the following order
[HDMI-A-2 HDMI-A-1], with my primary (as in, the monitor I use!) being HDMI-A-1.

KRunner will *always* open in my second screen (HDMI-A-2). Always, so will Kickoff if it's on two panels. 

This happens using either KScreen, KDisplay/Disman and KScreen directly from Git master.

STEPS TO REPRODUCE
1. Dual monitor system
2. Have main monitor to the right of the monitor you use
3. Use "active screen follows mouse"
4. Everything opens on the secondary monitor

OBSERVED RESULT
KRunner and other windows (kickoff, for example) open on the monitor where the mouse is at.

EXPECTED RESULT
A lot of windows open on the "secondary" monitor

SOFTWARE/OS VERSIONS
Linux: Linux 5.10.1-arch1
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
KWin built from Git master to test if this happened on master. It does.
Comment 1 David Rubio 2020-12-18 06:28:33 UTC
Here's a video outlining the issue: https://www.youtube.com/watch?v=Zgf5tCjAJqQ&feature=youtu.be

Right now I'm running MR 507, *but* on KWin master without 507 applied, the same thing happens. Same on KWin 5.20.4 directly from Arch's repos.
Comment 2 David Rubio 2020-12-18 15:21:46 UTC
OBSERVED RESULT
KRunner and other windows (kickoff, for example) open on the monitor where the mouse is NOT at.

Sorry, I filed the bug at 4AM, and the observed result should say that ;w;
Comment 3 David Rubio 2021-01-11 05:13:12 UTC
The game osu! also always opens in the wrong monitor, aka any monitor where the cursor is *not* located at.

Firefox too, sometimes.
Comment 4 Vlad Zahorodnii 2021-01-11 07:42:53 UTC
Kickoff and KRunner position themselves. If they do it wrong, it's a plasmashell bug.

As for osu! and Firefox, they most likely position themselves on a wrong monitor. Either way, Firefox is placed as expected when running with native Wayland support. Given that these are two separate issues, I'll move this bug to plasmashell as it's mostly about kickoff and krunner.
Comment 5 David Rubio 2021-01-11 16:37:26 UTC
(In reply to Vlad Zahorodnii from comment #4)
> Kickoff and KRunner position themselves. If they do it wrong, it's a
> plasmashell bug.
> 
> As for osu! and Firefox, they most likely position themselves on a wrong
> monitor. Either way, Firefox is placed as expected when running with native
> Wayland support. Given that these are two separate issues, I'll move this
> bug to plasmashell as it's mostly about kickoff and krunner.

You're right. Thanks for moving it to the correct category :)


osu! runs on XWayland, so I guess it's a similar issue. Firefox on native wayland does position itself on the wrong monitor to me, but seems like only if I start it maximized. I'll file the bug upstream if you think that part it's a Firefox bug.
Comment 6 David Rubio 2021-01-15 17:42:48 UTC
As a small heads-up, this also happens to kscreenlocker. If I have my mouse focused on screen A, the password * chars will start to be shown on screen B.
Comment 7 Nate Graham 2021-08-17 01:50:06 UTC

*** This bug has been marked as a duplicate of bug 379475 ***