[PATCH 1/6] Add weston randr protocol
ppaalanen at gmail.com
Fri Mar 14 03:29:10 PDT 2014
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
> [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.
More information about the wayland-devel