[PATCH V2 0/8] Add weston randr protocol

[Bryce W. Harrington]

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.


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.

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.

Bryce