On Fri, 14 Mar 2014 09:34:28 +0000 "Wang, Quanxian" <quanxian.w...@intel.com> wrote:
> > > >-----Original Message----- > >From: Pekka Paalanen [mailto:ppaala...@gmail.com] > >Sent: Friday, March 14, 2014 4:13 PM > >To: Wang, Quanxian > >Cc: Jasper St. Pierre; Hardening; wayland-devel@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.w...@intel.com> wrote: > > > >> On Sun, Mar 9, 2014 at 10:34 PM, Wang, Quanxian > ><quanxian.w...@intel.com<mailto:quanxian.w...@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. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
