[PATCH 1/6] Add weston randr protocol

[Wang, Quanxian]

>-----Original Message-----
>From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
>Sent: Friday, March 14, 2014 6:29 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 09:34:28 +0000
>"Wang, Quanxian" <quanxian.wang at intel.com> wrote:
>
>>
>>
>> >-----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.
>
>Yes, I really mean the person looking at the monitor decides that it's not good,
>need to set some known working mode before he can continue.
>You've probably seen these "click ok within 30 seconds if the picture looks ok now,
>otherwise automatically reverts to the old mode" dialogs.
>
>> By the way, do we need provide a delete mode interface to delete the mode
>which is not right determined by developer?
>
>xrandr tool has it.
>
>It's all up to you, really, if you see it as a feature that an administrator or developer
>would use.
>
>But do keep in mind, that protocol interface is not a user interface.
>If someone makes GUI for weston-randr, and uses it to test a bunch of custom
>modes where the last one actually works, it could be ugly if the GUI tool leaves a
>bunch of non-working modelines in the server mode list. Then again, that list
>probably gets wiped on server restart, and the admin is supposed to write the
>good modeline into the server config file, so it becomes available by default.
>
>And then there is the question, how far is it reasonable to go with this
>weston-only tweaking protocol.
>
>Like if you don't want to support custom modelines now, they can be added later
>if needed, as long as the basic design here allows it. Do consider also your own
>needs on IVI.
>
>You should probably also look at the RandR X11 protocol, not what options xrandr
>tool has. After all, you are designing a protocol here, not a user interface. xrandr is
>just a user interface.
[Wang, Quanxian] Yes, I take randr X11 protocol as a basic reference and xrandr as a requirement to think about that. If we could provide randr function without protocol used, it will be the ideal case. However you know, we could not provide all without protocol. At least you need to talk with compositor and set the output properties. Actually if wl_output provides the property setting function, randr does not need additional protocol to do that. Our only work will only provide a client app to implement randr function (dynamically mode setting). Therefore Weston randr protocol, to some extent is partly implementation of wl_output which should be controlled. :) 

My plan is to firstly create the protocol and add randr basic functions to Wayland/Weston. When developer or admin like that, we could continue to add more functions and enhance them. And at the same time provide a flexible mechanism to add new functions based on the requirement and feedback. Like adding mode, deleting mode, DPI setting, output disable/enable...

So my objectives:
Provide basic randr functions in Weston/wayland for developers/admin. Mainly focus on dynamic properties setting of output. (scale, transform, mode set, move, query)
And then provide a flexible and extensible mechanism for following functions adding. Including error handling, error reporting...
>
>
>Thanks,
>pq