Fix GNOME Wayland mixed-DPI capture scaling

[lorenzo-di-gregorio]

Fixes #4871.

Summary

• keep GNOME Wayland portal crops at native resolution when the portal canvas already matches Qt's native screen coordinates
• size the Wayland capture surface and selection area in device-independent coordinates when raw screen geometry matches the screenshot pixel size
• retain the existing scaling path for X11 and for Wayland portal images whose scale differs from 1

Why

With a mixed-DPI GNOME Wayland layout, Qt 6.2 can report the DPR 2 monitor's geometry in native pixels while the GNOME portal returns a DPR 1 composite using the same native-coordinate canvas. The existing code crops the native-resolution monitor correctly, then scales it by DPR a second time. The result is a blurred preview with selection limited to the top-left quarter.

The guards in this change are based on the observed relationship between portal scale, screen geometry, screenshot pixel size, and DPR so that compositors which already expose logical geometry keep their current behavior.

Testing

• git diff --check
• cmake --build build --parallel 8
• ctest --test-dir build --output-on-failure (the build defines no tests)
• manually tested on Ubuntu 22.04.5, GNOME 42.9, Wayland, Qt 6.2.4 with:
  • 2560x1440 external monitor at DPR 1
  • 3840x2400 internal monitor at DPR 2
  • 4858x3840 portal composite at DPR 1

The patched build restores native sharpness and allows selection across the complete HiDPI monitor.

[borgmanJeremy]

Hello,

Appreciate the attempted fix, but I don't want to merge something that is specific to a specific Qt release (6.2) and a DE (gnome). If you can test this across a wide variety of DE's and Qt releases and post results I would take a second look at it.

[lorenzo-di-gregorio]

Thanks—this is a fair concern. I verified the screen metrics with both Qt 5.15.3 and Qt 6.2.4 on the same GNOME Wayland session; both report the HiDPI display as 3840x2400 with DPR 2. Removing my local QT_SCREEN_SCALE_FACTORS setting produces the same result, so this is not unique to Qt 6.2. Historical issue #265 also reports the same symptom with Qt 5.11.

However, I cannot provide meaningful coverage across other desktop environments. The portal does not expose enough per-monitor scaling information to distinguish this case reliably from backends that intentionally return a lower-resolution image, so removing the GNOME guard would be unsafe.

If a default-off compatibility option is acceptable, I can narrow the PR to that. Otherwise, I am happy to close it and leave #4871 as documentation of the issue and working workaround.