Currently, it is possible to set scaling mode for a monitor only if the monitor is internal (LVDS, eDP). This is done through xrandr:
$ xrandr --prop
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192
LVDS1 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
scaling mode: Full aspect
supported: None, Full, Center, Full aspect
$ xrandr --output LVDS1 --set "scaling mode" "Center"
However, it is not possible to do this for external panels (VGA, DVI, HDMI, DP). The "scaling mode" property is not exported for these panels. There are many use cases for it, mainly related to gaming. Also some medical software like electrocardiogram monitor can't be stretched.
The function is implemented on radeon drivers already.
(I simply copied the above description from bug: 80868)
Could somebody kind introduce the story why only LVDS and eDP have "scaling mode" property ?
From the driver, "scaling mode" will set pipe's PF_POS and PF_WIN, all pipes have this function, so I think all connectors maybe could have "scaling mode" property.
Historically, only the LVDS supported panel fitters. Flexible scalers that could be attach to any pipe were introduced with Ironlake, but nobody has written the code to apply them to anything other than LVDS/eDP (not even DSI!).
Could your team write the code to implement this ? One customer want to use this.
(In reply to XiongZhang from comment #3)
> hi, Chris:
> Could your team write the code to implement this ? One customer want to
> use this.
Feature requests like this need to come through proper internal channels.
Over a year later this is still unimplemented. This was proposed last year
but it died during review. Could it be reimplemented in any way that's acceptable upstream?
(In reply to Jani Nikula from comment #4)
> (In reply to XiongZhang from comment #3)
(In reply to Timo Aaltonen from comment #5)
> Over a year later this is still unimplemented. This was proposed last year
> but it died during review. Could it be reimplemented in any way that's
> acceptable upstream?
Hello Jani, Timo,
It's been a while since any update was made on this case. If this was followed up internally or discarded, could this bug be closed already?
First of all. Sorry about spam.
This is mass update for our bugs.
Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!
If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Closing, please re-open if still occurs.
Hi, I would still like to see this functionality implemented.
You are reporter of the issue currently having low priority. Do you still see issue. If so, please spesify clearly what is impact to you.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org'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.freedesktop.org/drm/intel/issues/23.