Skip to content

[GTK3] Wrong monitor positions reported on wlroots compositors

The previous GTK 3.24 release (3.24.42) includes a fix described as "Fix monitor sizes".

51b04c50

This seems to have inadvertently caused some issues on wlroots-based (and now aquamarine) compositors, whereby the gdk_monitor_get_geometry function now returns 0, 0 for the position of every monitor.

This issue did not occur prior to the GTK update.

I have tested it on the following:

  • Gnome 46.1
  • KDE Plasma 6.0.4
  • Sway (dcdb727)
  • Hyprland 0.40.0 - 0.42.0

On Gnome/KDE the positions are reported correctly, however the bug occurs on both Sway and Hyprland. I therefore initially suspected that the bug is wlroots-related, but emersion believes it is a GTK issue, hence opening the issue here.

The effect of this is that the gdk_display_get_monitor_at_point function now returns the 1st monitor always.

If you need any more info, let me know.

Steps to reproduce

A basic reproduction can be seen with the following Python 3 script (sorry I don't know C):

import gi
gi.require_version('Gdk', '3.0')
from gi.repository import Gdk

display = Gdk.Display.get_default()

def print_geometry(num):
    mon = display.get_monitor(num).get_geometry()
    print(mon.x, mon.y, mon.width, mon.height)

# add/remove entries according to the number of monitors (I have 3)
print_geometry(0)
print_geometry(1)
print_geometry(2)

Current behaviour

The above script results in all 3 monitors reporting a position of 0, 0.

# incorrect
λ python gtk-test.py
0 0 2560 1440 # DP-1
0 0 1920 1080 # DP-2
0 0 2560 1440 # DP-3

Expected outcome

In my case I have 3 horizontally aligned monitors, so I would expect the X positions to be offset by their widths according to their alignment:

# correct
λ python gtk-test.py
1080 0 2560 1440 # DP-1
0 0 1920 1080    # DP-2
2520 0 2560 1440 # DP-3

Version information

GTK version: 3.24.42 and 3.24.43 OS: Arch Linux Compositor: Hyprland/Sway (details above) Driver: NVidia Proprietary (tested 550 through 560)

Additional information

Although this issue uses a Python example, this issue is NOT Python-specfic. I have also observed this behaviour in gtk-rs.

Related issues: