[PATCH V2 0/8] Add weston randr protocol

[Fu Michael]

On 4/2/2014 10:52 AM, Bryce W. Harrington wrote:
> 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.
>

Indeed. Most importantly, giving user more confident when connecting a 
Linux Wayland PC to a projector, rather than joking with it as a ice 
breaker. ;)

> Bryce
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>