weston: weston randr protocol for testing and configuration

[Wang, Quanxian]

Note:
Take user as developer or admin for weston randr discussion (in the following discussion, I always think user as developer or admin).


>-----Original Message-----
>From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
>Sent: Thursday, March 27, 2014 6:35 PM
>To: Wang, Quanxian
>Cc: wayland-devel at lists.freedesktop.org
>Subject: Re: weston: weston randr protocol for testing and configuration
>
>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)?
[Wang, Quanxian] 
Ok, Xserver has xid, does user knows the XID from interface? They don't know except you provide that when they query(in command line). In development, If they want that, they need to talk with xserver before running randr request(complex process). The same as wayland, if we want to support that, we need update mode attributes in compositor. In current mode of compositor, mode has width, height, refresh and flags attribute and no others. Mode information and others are available in backend. Weston mode id(wid same as xid) will be allocated as unique id to identify a mode. Also we should provide this information when user query mode list. (This is also another request to be designed. Provide detailed mode timing information for user including wid).

So without xid, the origin right process for set mode is like that weston_randr_set_mode(hdisplay, hsync_start, hsync_end, ....), that means, before user set the mode, he needs to get all the parameters of mode information. But is it a real friendly user interface for common user? (10 or 11 parameters, except the structure is shared between client and compositor)

Of course there is another way provide a unique wid to mode, so user could use it when he want to set the assigned mode. But it will change some global structure of compositor.(if we provide wid for mode, I don't think it is only for mode, it should be for every elements of compositor. For example, output, mode, surface, view ..., so I don't want to add this at this time. It touches more.)

For friendly user interface to set mode, I plan to provide two ways for user. One is the detailed timing setting. Provide all the parameters which could identify the unique id(special user special request). Another is provide a simple interface, for example, only width, height or refresh and find the first one matched to set the mode(most of users will like that and most of time they are unique by these 3 parameters.)
At the same time, provide a request for user to list mode detailed timing information.
>
>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.
[Wang, Quanxian] xid is just one of method. They use index, name string, xid or preferred to identify the mode.
>
>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?

[Wang, Quanxian] no, My goal is to provide a flexible and simple interface for user to use. Your request will be taken into consideration. It doesn't matter whatever custom or standard.

>
>
>Thanks,
>pq