GNOME Bugzilla – Bug 772202
Handling of scaled monitors is broken
Last modified: 2016-11-10 20:34:57 UTC
Created attachment 336543 [details] pygi test script Setup: One 3840x2160 scale=2 screen. Gtk 3.22.0-29-gfa23641992e0fc1e On GNOME X11: I ran into a problem with Firefox where it would misplace (and clip) its tooltips and menus to the top-left quadrant. After some investigation I discovered that I could trigger it by manipulating outputs with xrandr while Firefox is running. The attached script outputs some geometry values pulled from GdkScreen and GdkMonitor objects. If given an output name, it will manipulate the output with xrandr before redisplaying the values. python test.py eDP1: Screen: 1920x1080 RootWindow: (x=0, y=0, width=1920, height=1080) Monitor 0: 3840x2160+0+0 scale 2 workarea 1920x1052+0+27 Screen: 960x540 RootWindow: (x=0, y=0, width=1920, height=1080) Monitor 0: 1920x1080+0+0 scale 2 workarea 1920x1052+0+27 Monitor geometry starts in device pixels even though it's documented to be in "application pixels". Screen geometry is correct. After fiddling with the outputs, monitor geometry is correct now while the screen geometry is way too small, fitting scale=4. Monitor work area remains correct all the time. GDK_SCALE=1 python test.py eDP1: Screen: 3840x2160 RootWindow: (x=0, y=0, width=3840, height=2160) Monitor 0: 3840x2160+0+0 scale 1 workarea 3840x2105+0+55 Screen: 3840x2160 RootWindow: (x=0, y=0, width=3840, height=2160) Monitor 0: 3840x2160+0+0 scale 1 workarea 3840x2105+0+55 Geometries are correct now. GDK_SCALE=1 gnome-calculator has scale=2 text on scale=1 widgets. GDK_SCALE=2 python test.py eDP1: Screen: 960x540 RootWindow: (x=0, y=0, width=1920, height=1080) Monitor 0: 1920x1080+0+0 scale 2 workarea 1920x1052+0+27 Screen: 960x540 RootWindow: (x=0, y=0, width=1920, height=1080) Monitor 0: 1920x1080+0+0 scale 2 workarea 1920x1052+0+27 Monitor geometries are correct now. Screen geometries are consistently wrong. GDK_SCALE=2 gnome-calculator has scale=4 text on scale=2 widgets. On GNOME Wayland: python test.py: Screen: 3840x2160 RootWindow: (x=0, y=0, width=0, height=0) Monitor 0: 3840x2160+0+0 scale 2 workarea 3840x2160+0+0 Screen and monitor geometry (and work area) are wrong now, all being in device pixels even though the scale is 2. Native Wayland apps (such as Nautilus or GNOME Terminal) have way too small context menus (small enough they're always scrollable) and misplace them in the top-left quadrant. XWayland seems to work fine, miraculously.
A bunch of random comments: - The workarea on a hidpi display seems to be 55px. Is that a bug in gnome-shell? - We round wrong. 55 device pixel workarea should be rounded to 28px in hidpi so that we don't assume too much space. For the following comments assume this setup: Monitor 0: 1920x1080 on the left with scale 1 Monitor 1: 3840x2160 on the right set to scale 2 In a bugfree, ideal world, they would report themselves as: Monitor 0: 1920x1080+0+0 scale 1 Monitor 1: 1920x1080+960+0 scale 2 Not that the hidpi monitor 1 starts at the coordinates 960x0 which is also the top center coordinate of the unscaled monitor 0. So: - Where would gdk_window_move(window, 960,0) move the window? Center top of monitor 0 or top left of monitor 1? - If gdk_window_get_position(window) reported 960,0 as the position, where would the window be? What would the proper way be to figure it out?
Created attachment 337330 [details] [review] gdkscreen-x11: Fix screen and monitor size calculation The monitors are already in scaled pixels, so scaling again when retrieving the screen size is wrong. With GDK_SCALE unset, the initial monitor sizes are unscaled, and when the xsettings client sets a scale > 1, the monitor sizes should be updated. The end result is that the monitor sizes start out wrong, and get corrected on the first xrandr event, while the screen size starts out right and becomes wrong after the event. This patch fixes Firefox misplacing menus and popovers when the xrandr configuration changes while it is running.
(In reply to Benjamin Otte (Company) from comment #1) I think your case would actually be overlapping monitors. When the document talks about app pixels it means a density-independent coordinate space, and it just happens to coincide with device space at scale=1. So, only the width and height of a monitor should be scaled with its own scaling factor. Transforming a monitor's position from device space to app space requires looking at the scale factors of the other monitors, but on Wayland that should be entirely a concern of the compositor.
Created attachment 338276 [details] [review] gdkscreen-x11: Fix screen and monitor size calculation Rebased patch to current gtk-3-22 HEAD.
Recent patches to mutter seem to have solved the problems on Wayland, but the X11 bug affecting Firefox, solved by the above patch, remains.
Comment on attachment 338276 [details] [review] gdkscreen-x11: Fix screen and monitor size calculation It's better than before, so let's go for it!
Attachment 338276 [details] pushed as cb53562 - gdkscreen-x11: Fix screen and monitor size calculation