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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel