GNOME Bugzilla – Bug 723420
Add support for XRandR transformation matrix
Last modified: 2018-09-21 16:37:27 UTC
It would be good if gnome supports (in pre and post 3.9 versions) XRandR features like full transformation matrix, output border property and panning/tracking area. User can apply these configurations using xrandr utility, but on hot-plug/unplug or configuration change event gnome-settings-daemon interact with these applied configuration and change them. You can disable xrandr module of gnome-settings-daemon but then you lose functionality in which monitor gets light-up automatically in previous configuration on hot-plug or screen-size gets adjust automatically when monitor gets unplug. This is first bug I am filling and I have patches to add this support, just some testing is remaining. If community is favourable to added support for all these features, then I will file more bugs to added these functionalities in pre and post 3.9 gnome.
Created attachment 267928 [details] [review] Patches to add support for XRandR transformation matrix in gnome Here is patches to add support for XRandR transformation matrix in gnome - libgnome-desktop/gnome-rr-config.c | 118 ++++++++------- libgnome-desktop/gnome-rr-private.h | 1 + libgnome-desktop/gnome-rr.c | 270 ++++++++++++++++++++++++++++++++++- libgnome-desktop/gnome-rr.h | 28 +++- 4 files changed, 362 insertions(+), 55 deletions(-) Please, let me know soon; so I could start work on new code too.
Created attachment 267929 [details] [review] gnome-rr: [01/05]Support for RandR transformations
Created attachment 267930 [details] [review] gnome-rr: [02/05]Support for RandR transformations
Created attachment 267931 [details] [review] gnome-rr: [03/05]Support for RandR transformations
Created attachment 267932 [details] [review] gnome-rr: [04/05]Support for RandR transformations
Created attachment 267933 [details] [review] gnome-rr: [05/05]Support for RandR transformations
Here (comments from 2 to 6) are patches to add support for XRandR transformation matrix in gnome - libgnome-desktop/gnome-rr-config.c | 118 ++++++++------- libgnome-desktop/gnome-rr-private.h | 1 + libgnome-desktop/gnome-rr.c | 270 ++++++++++++++++++++++++++++++++++- libgnome-desktop/gnome-rr.h | 28 +++- 4 files changed, 362 insertions(+), 55 deletions(-) Please, let me know soon; so I could start work on new code too.
Output transformation is now configured from gnome-settings-daemon directly. I also don't know what "output border property and panning/tracking area" are useful for. In general terms, the patches lack distinguishable subject names, and only seem to support X.org, which means that they're unsuitable to be merged in newer versions of GNOME (and we're not going to break the API of versions released as stable nearly a year ago). For each new property, please explain the use cases, and file a bug against mutter, which now handles the output configuration for both X.org and Wayland. Once the properties are added there, we can add the bindings to gnome-desktop.
Comment on attachment 267929 [details] [review] gnome-rr: [01/05]Support for RandR transformations Marking as needs-work as per comments.
Comment on attachment 267930 [details] [review] gnome-rr: [02/05]Support for RandR transformations Marking as needs-work as per comments.
Comment on attachment 267931 [details] [review] gnome-rr: [03/05]Support for RandR transformations Marking as needs-work as per comments.
Comment on attachment 267932 [details] [review] gnome-rr: [04/05]Support for RandR transformations Marking as needs-work as per comments.
Comment on attachment 267933 [details] [review] gnome-rr: [05/05]Support for RandR transformations Marking as needs-work as per comments.
Thanks Bastien, Here is some benefits and/or use-cases - 1) RandR CRTC Transformations: ---- Projector keystone correction ---- Mode Scaling ---- Mode rotations 2) Output Border: ---- Overscan compensation (e.g. on TVs with always-on overscan) ---- Letterboxing/pillarboxing when scaling modes with different aspect ratios 3) panning and tracking area: ---- Allowing a large virtual screen (or a larger screen that is mirrored) to be panned on a small physical display. ---- Conversely, prohibiting a small physical display that is displaying a specific portion of the desktop from panning to another area. Some other use-cases are - ---- Digital Displays (such as TMDS, LVDS, Displayport) can generally only accept the modes advertise in EDID. To achieve any other desktop resolution, GPU has to scale the desktop resolution to one of the EDID-reported mode. ---- Mirror contents between two monitors with different native resolutions. This comes up all the time with a notebook + conference room projector: I'd like to drive the projector at its native resolution, and then aspect scale that same image to my notebook internal panel. I already described in bug description that - *Power user can apply these configurations using xrandr utility, but on hot-plug/unplug or configuration change event gnome-settings-daemon interact with these applied configuration and change them. You can disable xrandr module of gnome-settings-daemon but then you lose functionality in which monitor gets light-up automatically in previous configuration on hot-plug or screen-size gets adjust automatically when monitor gets unplug.* I know that code to handle output configuration is moved to mutter, and have plane to add this support there too. I will take look to mutter's code but before that - > For each new property, please explain the use cases, and file a bug against > mutter, which now handles the output configuration for both X.org and Wayland. > Once the properties are added there, we can add the bindings to gnome-esktop. does this mean we could back-port this support in last stable gnome-desktop release?
(In reply to comment #14) > Thanks Bastien, > > Here is some benefits and/or use-cases - You seem to be listing things that would then be technically possible, not what the users would actually be using them for. > 1) RandR CRTC Transformations: > ---- Projector keystone correction > ---- Mode Scaling > ---- Mode rotations We can already do simple rotation. Keystone correction might be something useful, though most projectors do have this feature builtin. Why would we want to change the keystone in the computer rather than on the projector itself? > 2) Output Border: > ---- Overscan compensation (e.g. on TVs with always-on overscan) > ---- Letterboxing/pillarboxing when scaling modes with different aspect ratios > > 3) panning and tracking area: > ---- Allowing a large virtual screen (or a larger screen that is mirrored) > to be panned on a small physical display. > ---- Conversely, prohibiting a small physical display that is displaying a > specific portion of the desktop from panning to another area. I don't think that supporting random resolutions/aspect ratio combinations is really something that's appealing to us, but the overscan compensation (eg. how do I see my whole desktop on this TV) is certainly something that would be interesting. > Some other use-cases are - > ---- Digital Displays (such as TMDS, LVDS, Displayport) can generally only > accept > the modes advertise in EDID. To achieve any other desktop resolution, GPU has > to > scale the desktop resolution to one of the EDID-reported mode. > ---- Mirror contents between two monitors with different native resolutions. > This comes up all the time with a notebook + conference room projector: > I'd like to drive the projector at its native resolution, and then aspect > scale that same image to my notebook internal panel. The inverse is usually what people want to achieve. > I already described in bug description that - > *Power user can apply these configurations using xrandr utility, but on > hot-plug/unplug > or configuration change event gnome-settings-daemon interact with these applied > configuration > and change them. You can disable xrandr module of gnome-settings-daemon but > then you lose > functionality in which monitor gets light-up automatically in previous > configuration > on hot-plug or screen-size gets adjust automatically when monitor gets unplug.* > > I know that code to handle output configuration is moved to mutter, > and have plane to add this support there too. s/too/instead. There would be no X or Wayland specific code in gnome-desktop. > I will take look to > mutter's code but before that - > > > For each new property, please explain the use cases, and file a bug against > > mutter, which now handles the output configuration for both X.org and Wayland. > > Once the properties are added there, we can add the bindings to gnome-esktop. > > does this mean we could back-port this support in last stable gnome-desktop > release? The latest stable is for GNOME 3.10, which already uses the same gnome-desktop/mutter split, so you could somewhat easily backport changes you'd make to mutter. But given that we're already nearing hard freeze for GNOME 3.12, your code, once we've found out exactly what we'd accept, is unlikely to make it in before GNOME 3.14. In any case, I'm not sure that discussing the raw gnome-desktop APIs on top of XRandR is going to bring this discussion forward in the short term. We would only add new APIs to enable new use cases (whether in the gnome-control-center display panel, or related components). So the best way forward is filing bugs (ideally one per use case) against gnome-control-center's Display panel, and discussing those particular use cases separately with the designers. Let us know when you've filed the bugs, we can discuss specifics either on bugzilla, or on IRC with the designers.
Sorry for delay to respond, I have filed following bug - 725139 gnome-control-center - Add support to configure panning 725136 mutter - Add support for XRandR panning and tracking 725135 gnome-control-center - Add support to configure display border 725133 mutter - Add support for XRandR output border property 725132 gnome-control-center - Add Support to configure desktop scaling 725130 mutter - Add support for XRandR Crtc full transformation matrix support As I mentioned in description of this bug, my main concern is that since mutter/gnome-desktop is not aware about transformation-matrix/panning/output-border when user configure them using xrandr, or some other interface they could not persist across hot-plug/unplug.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-desktop/issues/53.