[PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

>-----Original Message-----
>From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
>Sent: Friday, March 14, 2014 4:13 PM
>To: Wang, Quanxian
>Cc: Jasper St. Pierre; Hardening; wayland-devel at lists.freedesktop.org; Zhang,
>Xiong Y; Matthias Clasen; Jason Ekstrand
>Subject: Re: [PATCH 1/6] Add weston randr protocol
>
>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?
[Wang, Quanxian] got that.
>
>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.
[Wang, Quanxian] Fine, drmModeSetCrtc will need more parameter which is from mode_info. like weston.ini or newmode in xrandr 
We create drm modeinfo by these arguments. It need a new interface to do that. I will plan it in new interface.
>
>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.
[Wang, Quanxian] if you set the custom mode, basically we could not get the result if it is right or not, it is based on the response from developer's view. But we provide the interface to let them reset the mode. 
By the way, do we need provide a delete mode interface to delete the mode which is not right determined by developer?
>
>
>Thanks,
>pq