>-----Original Message----- >From: Pekka Paalanen [mailto:[email protected]] >Sent: Thursday, March 27, 2014 9:06 PM >To: Jasper St. Pierre >Cc: Wang, Quanxian; [email protected] >Subject: Re: weston: weston randr protocol for testing and configuration > >On Thu, 27 Mar 2014 08:31:34 -0400 >"Jasper St. Pierre" <[email protected]> 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 <[email protected]> >wrote: >> >> > On Thu, 27 Mar 2014 04:08:15 +0000 >> > "Wang, Quanxian" <[email protected]> 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 >> > [email protected] >> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > >> >> >>
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
