Re: [PATCH V2 0/8] Add weston randr protocol
On Wed, Apr 02, 2014 at 07:34:11AM +, 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
RE: [PATCH V2 0/8] Add weston randr protocol
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.harring...@samsung.com] >Sent: Wednesday, April 02, 2014 10:53 AM >To: Wang, Quanxian >Cc: wayland-devel@lists.freedesktop.org; ppaala...@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
Re: [PATCH V2 0/8] Add weston randr protocol
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
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. 2. Automatic detection of external configs When multiple video cards
