[PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

On Fri, 14 Mar 2014 02:33:52 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

> On Sun, Mar 9, 2014 at 10:34 PM, Wang, Quanxian <quanxian.wang at intel.com<mailto:quanxian.wang at intel.com>> wrote:
> 
> >> 5) mode setting parameters control
> >> Mode and output will be under the control. User could not randomly to set their
> >mode. They have to select the available modes and outputs provided by
> >compositor. Don't allow random mode setting. The mode and output information
> >could be provided by weston-randr apps or wl_output interface.
> >
> >I don't think that allowing to set only announced modes is a good idea.
> >The RDP compositor is a good example where you can't know the supported
> >modes (as nearly all modes can be supported).
> >
> >IIRC depending on the drivers, drm can also set arbitrary modes.
> [Wang, Quanxian] so, let user set the mode without limitation? Not sure if we should support that.
> Any comment for this requirement?

Not a user, but an administrator or developer, remember?

If we ignore all the "no real hardware" cases like RDP, VNC, and other
stuff where the screen is actually a window on another system and so
can be of any size, the following come to mind:

- using the monitor hardware for scaling instead of the GPU

- getting the native mode a display that has broken or missing EDID, as
  a workaround

We have the support for arbitrary modelines already in weston's config
file. Note that arbitrary size WxH is not enough, sometimes you need
the whole timings to be custom. See the ModeLine directive for
xorg.conf, and the arguments of xrandr --newmode.

While designing the interface, it would be nice to be able to easily
reset to a known working mode, if the new mode doesn't work
(modesetting succeeds, but the monitor does not like the signal). That
means that if you first query/get the current mode, then switch to a
new one, you can still switch back to the original exact mode even if
it was a custom mode. There is probably a good reason why xrandr has
--newmode/addmode/mode instead of only --mode.


Thanks,
pq