weston: weston randr protocol for testing and configuration

[Wang, Quanxian]

>-----Original Message-----
>From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
>Sent: Thursday, March 27, 2014 9:06 PM
>To: Jasper St. Pierre
>Cc: Wang, Quanxian; wayland-devel at lists.freedesktop.org
>Subject: Re: weston: weston randr protocol for testing and configuration
>
>On Thu, 27 Mar 2014 08:31:34 -0400
>"Jasper St. Pierre" <jstpierre at mecheye.net> wrote:
>
>> I don't think the user really knows what refresh is either.
>>
>> I'm actually curious: is there a reason to ever expose different modes
>> to the user that have the same width/height but different timings?
>> What's the rationale for choosing one instead of the other? I know
>> nothing about display panels, keep in mind.
>
>This is not for users, the whole weston-randr protocol is for developer and
>administrator tools for testing different modes without having to restart Weston
>and edit a config file in between.
>
>I cannot see a reason to offer the same mode with different timings during normal
>operations, but it would be useful for the very kind of experimentation that this
>protocol extension is designed for.
>
>At least, as far as I have understood. How far this interface should go is still unclear
>to me. If Quanxian wants to stick with RandR 1.1 features, i.e. no dynamic custom
>modelines, that's ok, though to me it seems like losing a good part of the possible
>benefits.
[Wang, Quanxian] RandR protocol is just a reference. We take the ideas from it based on wayland/weston current mechanism. Custom should be supported. In my v2, I have provided newmode request, it provides the custom mode. But it is need to be enhanced in the future. I am planning to provide two ways for common and special case.
>
>> I'm also assuming a modern system here with a modern display panel, so
>> no saying "the refresh means the CRT updates faster and it's brighter
>> and less less flicker"
>
>My 1600x1200 monitor, connected via DVI-D, was unstable, going black once in a
>while when ran with a normal timings mode at 60 Hz. Switching to reduced
>blanking mode made it stable and got rid of the random green snow. Yes, you can
>blame the hardware being on its edge.
>
>The refresh rate was exactly the same. The reduced blanking mode just made the
>pixel clock a bit lower, enough to make the picture stable.
>
>
>Thanks,
>pq
>
>> On Thu, Mar 27, 2014 at 6:35 AM, Pekka Paalanen <ppaalanen at gmail.com>
>wrote:
>>
>> > On Thu, 27 Mar 2014 04:08:15 +0000
>> > "Wang, Quanxian" <quanxian.wang at intel.com> wrote:
>> >
>> > > Hi, Pq
>> > >
>> > > The information to identify the unique mode: width, height and
>> > > refresh
>> > are enough? Not enough in theory. But is enough in real world. I
>> > have checked with xrandr. Read the following comment.
>> > >
>> > > Welcome any comment for that.
>> > >
>> > > Thanks
>> > >
>> > > >> +
>> > > >> +    <request name="set_mode">
>> > > >> +      <description summary="set the mode of output">  Set the
>> > > >> + mode of output.
>> > > >> +      </description>
>> > > >> +      <arg name="output" type="object" interface="wl_output"
>> > > >> +           summary="the output object"/>
>> > > >> +      <arg name="width" type="int" summary="width of the mode
>> > > >> + in
>> > > >hardware units"/>
>> > > >> +      <arg name="height" type="int" summary="height of the
>> > > >> + mode in
>> > > >hardware units"/>
>> > > >> +      <arg name="refresh" type="int" summary="vertical refresh
>> > > >> +rate in mHz"/>
>> > > >
>> > > >So this is the simple mode set request.
>> > > >
>> > > >Do you think width/height/refresh is really enough to identify a mode?
>> > I don't
>> > > >think so. I think in the early days of X11 RandR, NVidia hit the
>> > > >same
>> > problem, and
>> > > >started to expose fake refresh values, only to be able to
>> > > >distinguish
>> > modes that
>> > > >were identical in width/height/refresh but still different in timings.
>> > Or actually I
>> > > >think it was much more complicated than that, but this is the
>> > > >point in
>> > simple terms.
>> > > >
>> > > >So we need something else here to identify a mode.
>> > > >
>> > > >Check what kind of protocol GNOME uses, and how current RandR
>> > > >protocol
>> > works.
>> > > [Wang, Quanxian] Hi, Pq
>> > > Your understanding are right in theory. But in reality, it is
>> > > barely
>> > possible. Width and height could be easily same, not easy for
>> > refresh at the same time. Currently in xrandr, they use mode name to
>> > identify one mode (for example widthxheight_refresh). in xrandr
>> > process, I don't find they take mode information to compare. Maybe I
>> > missed, but from xrandr parameters, there is no such option. They
>> > just take width, height, refresh as mode name to identify one mode.
>> > Sometimes, only width and height. If we want to fully support one
>> > unique mode, all the mode information have to be compared. (clock,
>> > hdisplay, hsync_start, hsync_end, htotal, vdisplay, vsync_start,
>> > vsync_end, vtotal, flags). But it is not convenient. Sometime, user
>> > basically don't know what hdisplay is at all. They just know
>> > widthxheight_refresh. My idea is just take width, height, refresh as the unique
>id for mode.
>> > >
>> >
>> > I assume the X server has the database of modes. I cannot think of
>> > any reason why the xrandr client would be comparing modes at all.
>> > Why did you expect that? Isn't the name of a mode in RandR just an
>> > arbitrary string (perhaps mapped to an XID)?
>> >
>> > These were introduced in RandR 1.2 according to the xrandr man page.
>> > If you are looking at RandR 1.1, it is not sufficient for
>> > distinguishing custom modes.
>> >
>> > Say, how will you separate a normal mode from a reduced-blanking mode?
>> > They can have the same width, height, and refresh rate, but one
>> > works while the other is not reliable. I have had such monitors before.
>> >
>> > Of course, you have the choice to not support custom modes with
>> > custom timings. Is your intention to support only custom modes with
>"standard"
>> > timings, but not with custom timings? If so, which standard do you
>> > pick? VESA CVT?
>> >
>> >
>> > Thanks,
>> > pq
>> > _______________________________________________
>> > wayland-devel mailing list
>> > wayland-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>> >
>>
>>
>>