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 <[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 > -- Jasper
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
