weston: weston randr protocol for testing and configuration

[Jasper St. Pierre]

I mean, I'm mostly talking about user configuration in the case of a
desktop, when the user wants to change the mode of the display.

Obviously, it would be best if we could detect hardware edge cases like
that where it's going on the fritz and showing a green tint automatically,
and simply not offer the user a broken mode in the first place, but I don't
want to get a scolding from Adam Jackson, so I'll shut up.


On Thu, Mar 27, 2014 at 9:05 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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.
>
> > 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
> > >
> >
> >
> >
>
>


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