[PATCH V2 0/8] Add weston randr protocol

[Bryce W. Harrington]

On Wed, Apr 02, 2014 at 07:34:11AM +0000, Wang, Quanxian wrote:
> 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?

By that I mean a structured data format.  That could be a C struct, an
XML schema, a JSON file, INI file...  As a starting point I would
recommend looking at GNOME's ~/.config/monitors.xml file as an example.
(Probably worth looking at what KDE's configuration tools use too, and
maybe even Mir.)  Basically it's a static layout describing how the
given set of display equipment needs to be set up.

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

Right.  It wouldn't have to be XML, although that might be the most
logical format, but if there's already an established wire format for
structured data use that.  But that's the idea - make it a single
transaction, rather than a series of pokes and peeks.

> More comments below.
> 
> >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? 
> 

Right, you'd receive the configuration layout in some structured data
format, then internally you'd work out how to achieve that layout by
setting resolutions, rotations, translations, CRTC shuffling, and so
on.

Where this will show itself as better, I believe, is in the debugging.
When you provide the user with a bunch of atomic operations to do their
configuration, then there can be multiple paths they might take to get
from config A to config B.  One user might translate the display, then
scale it to correct resolution; another might do it the other way
round.  And you could have a bug that crops up when you do it one way
but not the other.  Testers would need to parametrically test every
possible path from config A to B.

Now consider that we're starting to see graphics cards able to drive 3+
monitors, and hybrid graphics systems, and multi-video cards, and
hotplugging amongst all the above.  All this adds more and more
variables for the user to go from A to B - and a combitorial nightmare
of test cases for the tester!

But with a transactional approach, the user isn't involved in any of
these decisions, and your implementation can establish a single way to
get from A to B, all under your programmatic control.  Testing becomes
majorly simplified.  Bug reproduction becomes quite straightforward -
you don't need much more than their config structure.

None of this is really new thinking - the fewer knobs and levers you
give the user, the less chance for things to go wrong.

And even though your targeted use case is administrators and testers,
well I think it works to their advantage too.  The tester might
programmatically generate a set of configuration xml files for the range
of things they want to test, and then just iteratively toss them at
wayland and see what happens.  The administrator would identify the
optimial 2 or 3 configs she wants to provide to her users, store the XML
in her configuration control system, and disseminate configuration
updates through her normal update processes.

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

I'll elaborate on the 'letterboxed' option.  Currently if you hook up
some unknown projector to your laptop and fire it up, you'll typically
find that both get mirrored, since X doesn't know anything about how
they should be configured.

But quite typically, the projector is going to be at a 4:3 aspect ratio,
vs. the laptop's 16:9 or 16:10, so none of the native resolutions of
either projector or laptop are going to match up.  X drops down to the
lowest common denominator - one of the VESA resolutions, like 1024x768.
Yet this is pretty much guaranteed to be the *last* thing the user
wants.

What I think the user likely wants is for their content to be displayed
on the projector at the best possible resolution, and for it to be
displayed on their laptop at their laptop LVDS's best resolution.  On
the laptop it should show the content in the same aspect ratio, by
adding black bars on either side.  So that's what I mean by
letterboxing.

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

You should also check out how display configuration is currently being
done on OSX and Windows.  Last I looked at them, they both had
streamlined it a good bit, and that's the style of operation users
expect now.  But I think there's still room to do even better, still.

Bryce