GNOME Bugzilla – Bug 725133
Add support for XRandR output border property
Last modified: 2021-07-05 13:53:13 UTC
XRandR have support to configure border for output, border dimensions shrink the region of pixels displayed by the CRTC by the corresponding number of rows or columns, and is applied after the CRTC transform. This is use-full for - ---- Overscan compensation (e.g. on TVs with always-on overscan) ---- Letterboxing/pillarboxing when scaling modes with different aspect ratios I will provide patch for this support, but first please let me know whether this all make sense or not?
Can you extend on what you think Mutter should do about overscan compensation? I can already use the underscan* drm properties in nouveau (for example, radeon also has them) for compensating against overscan, without any changes to Mutter. What could be useful is some addition to GNOME's control panel to set those borders.
I know that there is already a way to configure underscan and/or output border property, using 'xrandr' command you can configure every thing which xrandr protocol support; but does these settings persist across reboot or hot-plug/unplug of display? Answer is *No*. Mutter interfere with or does not persist settings like full-transformation- matrix/panning/output-border-property, because it is not aware about these settings. Then you lose functionality in which monitor gets light-up automatically in previous configuration on hot-plug.
Ah, now I see what you mean. Then you want to file this bug in gnome-settings-daemon I guess, it has a xrandr plugin that could persist those properties. I would try to make sure the title and description of the bug match what you mean though.
code of display/monitor handing is moved from gnome-settings-daemon to mutter, correct?
Yes, the code handling xrandr interactions lives in mutter. I will be happy to accept a patch that configures those properties, provided that implementations exists for X and for DRM, for the three major drivers (i915, radeon, nouveau), but only after the configuration for this is deemed worth of inclusion in gnome-control-center.
I'll keep the scaling/aspect side of things out of this bug and focus solely on border. After some discussions on IRC the major need for this isn't really about customizing the display setup but our inability to read display capabilities. To be able to present everything that we paint on the edges of the screen, we might need to only paint to a subsection of the supposed drawing area of the display ("crop"). Exposing configuration of this is our little UI defeat, it's the equivalent of admitting we can't do the right thing. It has been mentioned there is no way to keep an updated database of display capabilities due to the growing number of displays and many duplicate identifiers (EDID) giving a high chance of false positives. So we should present this very subtly so that it is accessible when indeed the user is having a problem, minimizing the UI "pollution" for all the cases when display just works. Here's the initial wire for configuring the border: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-settings/displays/xrandr-borders.png There might be types of displays where we can be certain the claimed resolution is visible, such as laptop screens/LVDS. We should omit that link from the panel.
Endless has a variety of fun patches to support this. I'm going to look at redoing some of these upstream.
Endless's patches are really awful. I added some minor support to be able to set "underscanning" as a boolean, but we're not going to look into configurable borders for a bit until more DDXen and DRM drivers have support for this.
Still relevant after the patches from bug 748560 against gnome-desktop, and the related mutter changes?
Yes. Intel doesn't support underscanning natively in its driver, so Endless has a downstream hack to xf86-video-intel to do some awful shenanigans, which we can't really port here.
Cosimo is landing the UI part for GNOME 3.22, and the API is also in gnome-desktop (which I'm guessing always returns FALSE for whether it supports underscan).
(In reply to Bastien Nocera from comment #11) > Cosimo is landing the UI part for GNOME 3.22, and the API is also in > gnome-desktop (which I'm guessing always returns FALSE for whether it > supports underscan). It won't always return FALSE, as some drivers actually do support this upstream (but not the Intel driver).
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.