Bug 445158

Summary: Yakuake does not open on the screen where the mouse pointer is
Product: [Applications] yakuake Reporter: phrxmd <philipp.reichmuth>
Component: generalAssignee: Eike Hein <hein>
Status: CLOSED FIXED    
Severity: normal CC: brix, firlaevhans.fiete, Flupp+bugs.kde.org, hello, ilker4fun, jendal, mistry01, morashonjenkins, nate, nick.sev, nicolas.fella, paul, RBredereck, rossporter506, rulatir
Priority: NOR Keywords: wayland
Version: 21.08.2   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 22.08
Sentry Crash Report:

Description phrxmd 2021-11-08 13:20:52 UTC
SUMMARY
On Wayland, Yakuake always opens on a particular screen. I would prefer it to open on the screen with the mouse pointer, just like KRunner does in X11.

STEPS TO REPRODUCE
1. With multiple monitors, invoke Yakuake.
2. Move the mouse pointer to another monitor and invoke Yakuake again.

OBSERVED RESULT
Yakuake always opens on a particular screen - in my case my notebook's screen, which happens to be the leftmost screen.

EXPECTED RESULT
Yakuake should open on the screen where the mouse pointer is, like KRunner does on X11.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20211105
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.14-1-default (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

ADDITIONAL INFORMATION
Some people might prefer it to open always on a particular screen, so "follow the mouse"  could be a configuration option.
Comment 1 Firlaev-Hans 2021-11-13 17:34:42 UTC
Can confirm on KDE Neon unstable.

Oddly enough when I tried it yesterday on my main (Arch Linux) PC on Wayland I could NOT confirm this, Yakuake actually DID open on the screen with the mouse. However, it was not resized correctly for the secondary monitor which has a lower resolution, thus it was cut off to the right.
I have not found any configuration difference between the two machines that would explain the different behavior (both were also running the master build of Yakuake)
Comment 2 m1st0 2021-12-15 17:56:00 UTC
EXPECTED RESULT
Yakuake should open on the screen where the mouse pointer is on Wayland, like KRunner or Yakuake does on X11.
Comment 3 m1st0 2021-12-15 18:06:48 UTC
(In reply to m1st0 from comment #2)
> EXPECTED RESULT
> Yakuake should open on the screen where the mouse pointer is on Wayland,
> like KRunner or Yakuake does on X11.

Sorry, should have confirmed rather than noted unnecessary semantics. Confirmed on Kubuntu 21.10, KDE Plasma 5.23.0.
Comment 4 ilker 2022-02-15 08:21:25 UTC
Can confirm that it doesn't working on Kde Neon with 5.24.0
Comment 5 morashon 2022-02-21 13:27:37 UTC
Confirm on Manjaro KDE Plasma 5.23.5
Comment 6 Nick 2022-03-16 08:38:59 UTC
Confirm on EndeavourOS with KDE Plasma 5.24.3
Comment 7 Nate Graham 2022-04-11 20:25:40 UTC
Git commit ae055c29d7f4fb2ca5e8406410611ffb499f5028 by Nate Graham, on behalf of Martin Seher.
Committed on 11/04/2022 at 20:25.
Pushed by ngraham into branch 'master'.

On Wayland, show on active output

QCursor::pos does not work under wayland. So use active output from KWin
to determine startup screen, if not configured otherwise.

M  +14   -0    app/mainwindow.cpp

https://invent.kde.org/utilities/yakuake/commit/ae055c29d7f4fb2ca5e8406410611ffb499f5028
Comment 8 Nate Graham 2022-05-25 16:25:04 UTC
*** Bug 454369 has been marked as a duplicate of this bug. ***
Comment 9 ttv200 2022-08-23 07:25:59 UTC
*** Bug 440825 has been marked as a duplicate of this bug. ***
Comment 10 Thomas Brix Larsen 2022-08-26 20:42:00 UTC
This no longer works on Xorg after upgrading to Yakuake 22.08.0 (on Arch Linux). Downgrading Yakuake to 22.04.3 restores the functionality. KRunner is also affected.
Comment 11 Szczepan Hołyszewski 2022-09-04 12:42:48 UTC
Experiencing this with Yakuake 2022.04.3 as well.
Comment 12 Nate Graham 2022-09-04 13:19:14 UTC
(In reply to Szczepan Hołyszewski from comment #11)
> Experiencing this with Yakuake 2022.04.3 as well.

As the "Version fixed in" field says, this is expected to be fixed in version 22.08.
Comment 13 Szczepan Hołyszewski 2022-09-04 13:34:38 UTC
Sorry, I got confused because Thomas Brix Larsen above said that _downgrading_ to 2022.04.3 fixed this for him. But it seems that he was in fact reporting a regression on X caused by this fix?
Comment 14 Flupp 2024-07-21 20:39:30 UTC
I am not sure if it is right to comment on this closed ticket. However, for me, the problem as described in the summary is not (or not anymore) fixed.

There are other open issues that seem to be about the same or a similar problem, see bugs 383555, 481966.

I actually came here after Git-blaming the QDBus call to KWin’s activeOutputName in app/mainwindow.cpp (see comment 7). It seems that activeOutputName does not always give a result that fits the description “At mouse location”. Instead, it seems to either return the output of the focused window or the mouse pointer, depending on if the focus or the mouse position changed last. This can easily be verified by watching the output of `watch -n.1 qdbus org.kde.KWin /KWin activeOutputName` while Alt-tabbing between windows on different screens or wiggling the mouse on a particular screen.

Consequently, Yakuake opens on the screen with the focused window when window focus change was more recent than mouse move. Unfortunately, the focus change can be caused by Yakuake itself when it closes. This may lead to the the following IMO confusing behavior: Assume Yakuake is currently closed, a window is focused on screen 1 and mouse has recently moved on screen 2. When Yakuake is opened via the hotkey, it appears on screen 2. When Yakuake is closed via the hotkey, the window on screen 1 gets focused. Hence, when opening Yakuake again, it now opens on screen 1.

In `kcmshell6 kcm_kwinoptions`, I use the default window activation policy “Click to focus”. I tried other strategies, but those have other disadvantages for me. Setting focus stealing prevention to “Extreme” actually solves the issue, however, this does not feel right either.

I see the following questions now:

* What is the intended behavior of Yakuake regarding mouse position (and maybe window focus)?
* What is the intended behavior of activeOutputName?
* Do those two match?


PS:

While digging into the problem I added some printf debuging to Yakuake. There I noticed that activeOutputName is queried several times when Yakuake is opened or closed. Sometimes the result changes during the same open/close action. I think I only observed this on close actions, but, since this is inherently racy, I guess this can also happen when opening Yakuake. I cannot say if this has any bad implications; it’s just a hunch that it might have.

There are also bugs about wrong Yakuake window sizes (which I can also confirm), see bugs 482733, 485069, 488780. I was not able to confirm that those are related to the race, nevertheless I wanted to mention it.


Operating System: Arch Linux 
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.9.10-arch1-1 (64-bit)
Graphics Platform: Wayland (however, problem also occurs with X11)
Yakuake package version: 24.05.2-1