Incorrect xdg_output logical size for scaled outputs
Wine Wayland wants to take into account the (possibly fractional) scale used by compositors. The wp-fractional-scale-v1
protocol is the modern solution, but there are still several versions of compositors in the wild that do not support it. These tend to use the xdg-output logical size and wl_output mode info to communicate scale (both integral and fractional).
This is based on the following part of the xdg-output spec:
For example, for a wl_output mode 3840×2160 and a scale factor 2:
- A compositor not scaling the surface buffers will advertise a
logical size of 3840×2160,
- A compositor automatically scaling the surface buffers will
advertise a logical size of 1920×1080,
- A compositor using a fractional scale of 1.5 will advertise a
logical size of 2560×1440.
However, by default Mutter reports the same logical and physical sizes even though it autoscales buffers, so it violates case (2) above, and also the following spec paragraph:
For example, a surface without any buffer scale, transformation
nor rotation set, with the size matching the logical_size will
have the same size as the corresponding output when displayed.
Here is a sample Mutter output:
interface: 'wl_output', version: 3, name: 4
x: 0, y: 0, scale: 2,
physical_width: 290 mm, physical_height: 170 mm,
make: 'SHP', model: '0x144a',
subpixel_orientation: unknown, output_transform: normal,
mode:
width: 3200 px, height: 1800 px, refresh: 59.981 Hz,
flags: current preferred
interface: 'zxdg_output_manager_v1', version: 3, name: 5
xdg_output_v1
output: 4
name: 'eDP-1'
description: 'Built-in display'
logical_x: 0, logical_y: 0
logical_width: 3200, logical_height: 1800
Note that the expected (scaled) logical size is reported correctly by Weston, KWin, wlroots, Mir.
The current Mutter behavior confuses clients that also want to support pre-wp-fractional-scale-v1
compositors and infer the effective output scale from the logical/physical sizes. If this behavior is required for legacy reasons (e.g., XWayland) perhaps it makes sense to only apply it to XWayland clients by default?
Note that setting the scale-monitor-framebuffer
feature corrects this behavior.
Thoughts?