GNOME Bugzilla – Bug 783995
Monitor API inconsistencies across X11 & Wayland
Last modified: 2017-10-27 20:51:55 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
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.
Created attachment 354548 [details] [review] [PATCH 1/2] GdkMonitor: Use 1 as scale fallback value cherry-pick c78451e
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.
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.
Tested via jhbuild and correctly reports the expect resolution now on Wayland and X11.
*** Bug 788497 has been marked as a duplicate of this bug. ***
Review of attachment 354548 [details] [review]: sure
Review of attachment 354561 [details] [review]: looks right to me. do we know of any applications that are relying on the old behavior ?
(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.
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.