[PATCH V2 0/8] Add weston randr protocol

[Wang, Quanxian]

Thanks Bryce's information and suggestion. Your suggestion and randr history are really appreciated.

>As GUI interfaces came into being, they
>had to reinvent the user-oriented logic already in the xrandr tool, and besides the
>duplication of effort we saw the same mistakes made over and over.  If there had
>been a higher level library that implemented xrandr's user-friendly interface as a
>proper structured API, it would have made life much easier for the GUI
>configuration tool developers, and would have ensured better consistency and
>faster stabilization across the development community.
[Wang, Quanxian] I am very interested with these words. What is a proper structure?
Is it a whole layout or a xml stature to contain all configuration request? I found you like xml to store all requests.
When you want to configure, just generate a xml with your request and send it to display server. Server will help 
parse xml and do what user want to do. Is it right?

More comments below.

Regards

Thanks

Quanxian Wang
>-----Original Message-----
>From: Bryce W. Harrington [mailto:b.harrington at samsung.com]
>Sent: Wednesday, April 02, 2014 10:53 AM
>To: Wang, Quanxian
>Cc: wayland-devel at lists.freedesktop.org; ppaalanen at gmail.com
>Subject: Re: [PATCH V2 0/8] Add weston randr protocol
>
>On Mon, Mar 24, 2014 at 07:39:12PM +0800, Quanxian Wang wrote:
>> By the way, currently we are focus on the protocol design. The
>> implemented code is just a reference. However it will be helpful for
>> reviewer to have a test and get the clear idea of protocol. I like your comment to
>make this protocol stronger. Thanks.
>> Especially thanks to Pq. He gives me more valuable information. I will
>> continue keep tuning your comment and make the change.
>
>I haven't done a new review of the latest version of the protocol, but have been
>following the discussions so far.  I'd like to step back and offer some thoughts
>based on my experience with randr as Ubuntu's X.org maintainer for a good 7
>years.  Sorry this is so long and rambling; skip down to the end for my specific
>suggestions.
>
>
>I remember when randr was first introduced, and it was a godsend, because it
>allowed changing resolutions on the fly.  This was very important with the old
>CRTs because you often didn't have EDID information, and the best resolution was
>not always the highest, and you'd need to fiddle with refresh rates to get
>something that was easy to look at.  IOW, there was a lot of fiddling we expected
>of users.
>librandr and the xrandr tool gave users a way to do this fiddling without having to
>restart X.  GUI applications wrappering either librandr or xrandr sprung up over
>time, and after a lot of debugging we got to the relatively robust display
>configuration tools we have today.
>
>It's worth noting that librandr is a *very* low level protocol, compared with the
>more user-friendly CUI interface provided by the xrandr tool.
>It describes CRTCs, outputs, and so on.  As GUI interfaces came into being, they
>had to reinvent the user-oriented logic already in the xrandr tool, and besides the
>duplication of effort we saw the same mistakes made over and over.  If there had
>been a higher level library that implemented xrandr's user-friendly interface as a
>proper structured API, it would have made life much easier for the GUI
>configuration tool developers, and would have ensured better consistency and
>faster stabilization across the development community.
>
>So, I think that just reimplementing librandr's API as-is in Wayland isn't necessarily
>the best way to go.  Instead I think you want a high level API that says, "Put
>monitor A on the left at max resolution, and monitor B to the right at max res," as
>you would with xrandr, and leave all the detailed CRTC and whatnot operations as
>hidden internal details.
>
>When xrandr was developed, many things in display were non-standard.
>It was not unusual for monitors to not provide EDID, or to provide incorrect EDID,
>and mess up X's detection (there were lengthy lists of quirks and heuristics in the
>X drivers and Xserver to fixup specific hardware).  A lot of these issues are in the
>past.  You can assume the kernel handles a lot of this mess these days, and when
>there are discrepancies you treat them as simple bugs and don't really need tools
>to configure your way around them.
>
>The needs of users have also changed.  When randr was introduced, users
>wanted better configuration tools do set up their displays.  Having access to the
>configuration innards was a good thing.  Today's users want *no* configuration
>tools to be needed; the displays should come up at maximum resolution
>supported by the hardware and "just work" when plugged together with other
>hardware.
>
>For many of today's computing use cases, that is pretty much how it works.
>Tablets, embedded devices, single-display laptops, phones...
>Other than screen rotation the user won't have much need for display
>configuration.
>
>The one glaring exception is external display.  Plug a tablet into an external
>monitor, or a laptop into a projector.  randr's approach to give the user the tools
>to set these up, and it does give a very flexible set of controls.  However, users
>these days don't even want to do this degree of configuration.  At best, they
>want to hit a Fn key combo to toggle between mirrored, extended, etc.
>
>You've indicated the intended audience for this as testers and administrators.  I
>think as a tester or administrator I would not care about on-the-fly configuration
>changes, and actually would prefer locking down the settings in the wayland.ini file.
>But I may not understand the full breadth of uses you intend, so I'll assume you
>have good reasons for wanting on-the-fly changes, and offer these
>suggestions:
>
>
>1.  Keep the API very, very high level.
>
>Rather than providing individual routines to set this and that, define a data
>structure that will describe a static configuration of monitors, which you pass to
>Wayland for parsing and validating (and perhaps persisting it to disk in XML or
>whatnot).  A second call lets you activate a validated configuration (with 0 being a
>known-good default).
>A third one to delete a configuration.  Another to return a list of all stored
>configs.
[Wang, Quanxian] As a whole, the randr protocol data structure for configuration request should be consistent with xml layout. Whatever xml or data structure, the only objective is to store all the configuration requests from client. Xml will contain all the configuration request and routine exists for atomic operations. Everyone has their advantage. For xml, it will be useful for static configuration just like xorg.conf or weston.ini, therefore if it is for static, I prefer to use xml in weston.ini instead of randr protocol. For dynamic, atomic operation will be easy to store every request together. But your idea gives me some hints. If randr provides an interface to transfer xml file and parse it, then put the results into data structure which contain configuration requests(merge together). Will it be better? 

>
>
>2.  Automatic detection of external configs
>
>When multiple video cards and/or monitors are present, there should be a way to
>request a set of automatically determined static configurations, that can be
>selected from and passed directly to the API call in #1.
>For instance, given two physically identical monitors we can assume the user
>wants to lay them out side-by-side or above-and-below (or vice versa), and
>provide the four combinations.  The user can then hit a button or key combo to
>toggle between the four until it's right, and then click save.  Or if one of the
>displays looks like it might be a projector, provide a set of configs for letterboxed,
>mirrored, extended, etc.
[Wang, Quanxian] It is the whole layout of all outputs. Interesting. 
>
>There should be a hashing function used to id the various configs, so when you
>have a volatile combination (a laptop in a docking station, or a tablet periodically
>hooked in via USB, or etc.) the IDs of the displays are hashed together and used to
>look up which config to use.
>
>
>3.  No modeline fiddling
>
>Yes, even recently I've seen cases where users needed the ability to add their own
>modelines, and used xrandr's addmode/setmode stuff to do so.
>But I think we can do better.
>
>First, 90% of these cases are due to broken or missing EDIDs.  Modern kernels
>now permit adding edid's to /lib/firmware.  I think this ends up being a much
>more holistic solution, because you can supply them via the normal packaging
>system.  Then we'd just need to have this API provide a way to select amongst
>available EDIDs and notify the kernel to switch.
>
>Also, for the (hopefully increasingly rare) cases where users do need to fiddle
>modelines, this should rather be done by having them specify the desired
>resolution, refresh rates, etc. as the inputs, and calculate the modeline internally,
>saving it either to EDID or placing it into the data structure in #1.
>
>
>I think that covers everything.  Hopefully the above gives some useful food for
>thought in designing this, although maybe I'm just throwing a smelly fish on the
>table!  :-)  But I do think we can do better than just reimplementing randr, and
>come up with something that avoids many of the issues that have been driving
>users to need to configure things at all.
[Wang, Quanxian] Very useful. Different view and experience will remind what missed, what to be considered more. Thank Bryce.
>
>Bryce