After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783995 - Monitor API inconsistencies across X11 & Wayland
Monitor API inconsistencies across X11 & Wayland
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 788497 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-06-20 13:03 UTC by Christian Kellner
Modified: 2017-10-27 20:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[PATCH 1/2] GdkMonitor: Use 1 as scale fallback value (767 bytes, patch)
2017-06-27 09:32 UTC, Olivier Fourdan
committed Details | Review
[PATCH 2/2] wayland: scale down reported monitor geometry (1.72 KB, patch)
2017-06-27 09:33 UTC, Olivier Fourdan
none Details | Review
[PATCH 2/2 v2] wayland: scale down reported monitor geometry (2.60 KB, patch)
2017-06-27 12:33 UTC, Olivier Fourdan
committed Details | Review

Description Christian Kellner 2017-06-20 13:03:38 UTC
I stumbled across API inconsistencies in the monitor API.
The screen has a physical resolution of 3200 x 1800 and the session applies a scale factor of 2.

According to the API gdk_monitor_get_geometry uses "application pixels":
"* Retrieves the size and position of an individual monitor within the
 * display coordinate space. The returned geometry is in  ”application pixels”,
 * not in ”device pixels” (see gdk_monitor_get_scale_factor())."

I assume device pixel are physical pixel and application pixel are the effective pixel, after the scale factor has been applied. According to this only gtk3 on X11 reports the expected value. gtk3 on Wayland and gtk4 on both report 3200 x 1800.

Also the physical size and the model name changes across X11/Wayland. Less of a deal, but maybe good to document?

Test program is 
here: https://gist.github.com/gicmo/0b2ae88379b3af7622eefe47efebc5b4

--- 8< ---

Gtk+ version: 3.22.15
X11

Monitor: eDP-1 [0]
 293 x 165 [mm x mm]
 1600 x 900 [px]
 scale: 2

--- 8< ---

Gtk+ version: 3.22.15
Wayland

Monitor: 0x424a [0]
 290 x 170 [mm x mm]
 3200 x 1800 [px]
 scale: 2

--- 8< ---

Gtk+ version: 3.91.0
X11

Monitor: eDP-1 [0]
 293 x 165 [mm x mm]
 3200 x 1800 [px]
 scale: 2

--- 8< ---

Gtk+ version: 3.91.0
Wayland

Monitor: 0x424a [0]
 290 x 170 [mm x mm]
 3200 x 1800 [px]
 scale: 2
Comment 1 Olivier Fourdan 2017-06-27 07:48:32 UTC
On Wayland, the compositor reports the output size, scale and configuration, so any discrepancy would come from mutter, not gtk+.

You can use "weston-info" to check all the interfaces and their values.

Here, for wl_output, I get:

	interface: 'wl_output', version: 2, name: 5
		x: 0, y: 120, scale: 1,
		physical_width: 310 mm, physical_height: 170 mm,
		make: 'LGD', model: '0x040a',
		subpixel_orientation: unknown, output_transform: normal,
		mode:
			width: 1920 px, height: 1080 px, refresh: 60.008 Hz,
			flags: current preferred

	interface: 'wl_output', version: 2, name: 22
		x: 1920, y: 0, scale: 1,
		physical_width: 520 mm, physical_height: 320 mm,
		make: 'DEL', model: 'DELL U2412M',
		subpixel_orientation: unknown, output_transform: normal,
		mode:
			width: 1920 px, height: 1200 px, refresh: 59.950 Hz,
			flags: current preferred

mutter gets monitor specs, including physical size, from EDID, you could check what size EDID reports for your monitors.

Here, for the same, I get:

	$ edid-decode /sys/class/drm/card0-eDP-1/edid
	Extracted contents:
	header:          00 ff ff ff ff ff ff 00
	serial number:   30 e4 0a 04 00 00 00 00 00 17
	version:         01 04
	basic params:    95 1f 11 78 ea
	chroma info:     dc 95 a3 58 55 a0 26 0d 50 54
	established:     00 00 00
	standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
	descriptor 1:    ba 36 80 ac 70 38 24 40 3c 24 35 00 35 af 10 00 00 1a
	descriptor 2:    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
	descriptor 3:    00 00 00 fe 00 4c 47 20 44 69 73 70 6c 61 79 0a 20 20
	descriptor 4:    00 00 00 fe 00 4c 50 31 34 30 57 46 31 2d 53 50 4b 31
	extensions:      00
	checksum:        74

	Manufacturer: LGD Model 40a Serial Number 0
	Made week 0 of 2013
	EDID version: 1.4
	Digital display
	6 bits per primary color channel
	DisplayPort interface
	Maximum image size: 31 cm x 17 cm
	Gamma: 2.20
	DPMS levels: Standby Suspend Off
	Supported color formats: RGB 4:4:4, YCrCb 4:2:2
	First detailed timing is preferred timing
	Established timings supported:
	Standard timings supported:
	Detailed mode: Clock 140.100 MHz, 309 mm x 175 mm
		       1920 1980 2016 2092 hborder 0
		       1080 1083 1088 1116 vborder 0
		       +hsync -vsync 
	Manufacturer-specified data, tag 0
	ASCII string: LG
	ASCII string: LP140WF1
	Checksum: 0x74 (valid)
	EDID block does NOT conform to EDID 1.3!
		Missing name descriptor
		Missing monitor ranges
		Detailed block string not properly terminated

and:

	$ edid-decode /sys/class/drm/card0-DP-5/edid
	Extracted contents:
	header:          00 ff ff ff ff ff ff 00
	serial number:   10 ac 7a a0 53 59 4a 33 14 18
	version:         01 03
	basic params:    80 34 20 78 ea
	chroma info:     ee 95 a3 54 4c 99 26 0f 50 54
	established:     a1 08 00
	standard:        81 40 81 80 a9 40 b3 00 d1 c0 01 01 01 01 01 01
	descriptor 1:    28 3c 80 a0 70 b0 23 40 30 20 36 00 06 44 21 00 00 1a
	descriptor 2:    00 00 00 ff 00 30 46 46 58 44 34 35 47 33 4a 59 53 0a
	descriptor 3:    00 00 00 fc 00 44 45 4c 4c 20 55 32 34 31 32 4d 0a 20
	descriptor 4:    00 00 00 fd 00 32 3d 1e 53 11 00 0a 20 20 20 20 20 20
	extensions:      00
	checksum:        f5

	Manufacturer: DEL Model a07a Serial Number 860510547
	Made week 20 of 2014
	EDID version: 1.3
	Digital display
	Maximum image size: 52 cm x 32 cm
	Gamma: 2.20
	DPMS levels: Standby Suspend Off
	Supported color formats: RGB 4:4:4, YCrCb 4:2:2
	First detailed timing is preferred timing
	Established timings supported:
	  720x400@70Hz
	  640x480@60Hz
	  800x600@60Hz
	  1024x768@60Hz
	Standard timings supported:
	  1280x960@60Hz
	  1280x1024@60Hz
	  1600x1200@60Hz
	  1680x1050@60Hz
	  1920x1080@60Hz
	Detailed mode: Clock 154.000 MHz, 518 mm x 324 mm
		       1920 1968 2000 2080 hborder 0
		       1200 1203 1209 1235 vborder 0
		       +hsync -vsync 
	Serial number: 0FFXD45G3JYS
	Monitor name: DELL
	Monitor ranges (GTF): 50-61Hz V, 30-83kHz H, max dotclock 170MHz
	Checksum: 0xf5 (valid)
	EDID block does NOT conform to EDID 1.3!
		Detailed block string not properly terminated

Which matches the wl_output reported physical size.
Comment 2 Olivier Fourdan 2017-06-27 09:32:26 UTC
Created attachment 354548 [details] [review]
[PATCH 1/2] GdkMonitor: Use 1 as scale fallback value

cherry-pick c78451e
Comment 3 Olivier Fourdan 2017-06-27 09:33:03 UTC
Created attachment 354549 [details] [review]
[PATCH 2/2] wayland: scale down reported monitor geometry

According to the documentation, gdk_monitor_get_geometry() reports the
monitor geometry in ”application pixels”, not in ”device pixels”,
meaning that the actual device resolution needs to be scaled down by the
scale factor of the output.

x11 backend does that downscaling, whereas Wayland backend did not,
causing a discrepancy depending on the backend used.
Comment 4 Olivier Fourdan 2017-06-27 12:33:36 UTC
Created attachment 354561 [details] [review]
[PATCH 2/2 v2] wayland: scale down reported monitor geometry

According to the documentation, gdk_monitor_get_geometry() reports the
monitor geometry in ”application pixels”, not in ”device pixels”,
meaning that the actual device resolution needs to be scaled down by the
scale factor of the output.

x11 backend does that downscaling, whereas Wayland backend did not,
causing a discrepancy depending on the backend used.
Comment 5 Christian Kellner 2017-06-27 13:13:35 UTC
Tested via jhbuild and correctly reports the expect resolution now on Wayland and X11.
Comment 6 Robin Burchell 2017-10-04 16:11:58 UTC
*** Bug 788497 has been marked as a duplicate of this bug. ***
Comment 7 Matthias Clasen 2017-10-11 17:49:12 UTC
Review of attachment 354548 [details] [review]:

sure
Comment 8 Matthias Clasen 2017-10-11 17:54:25 UTC
Review of attachment 354561 [details] [review]:

looks right to me. do we know of any applications that are relying on the old behavior ?
Comment 9 Robin Burchell 2017-10-11 19:00:43 UTC
(In reply to Matthias Clasen from comment #8)
> Review of attachment 354561 [details] [review] [review]:
> 
> looks right to me. do we know of any applications that are relying on the
> old behavior ?

I am in gtkplatform, but once I know what version this fix will end up in, I'll muddle it to work with old and new versions.
Comment 10 Daniel Boles 2017-10-27 20:51:55 UTC
It's been pushed to the 3 and 4 branches, so it'll be in their next versions, 3.22.25 and 3.92.2.