weston: weston randr protocol for testing and configuration

[Jasper St. Pierre]

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.

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"


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
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140327/89f9119f/attachment.html>