RandR 1.2 feedback

[Andy Ritger]

Hi Keith,

I'm very sorry for taking so long to review the RandR 1.2 spec.  It looks
good.  I have just two main suggestions.

I read the version of the spec here:

     http://gitweb.freedesktop.org/?p=users/keithp/randrproto.git;a=blob;h=f0ec5e1326565e7008056159249df2329eab1156;hb=61d60a93dc0c827ef970f21f6b80099cc6c958f1;f=randrproto.txt


Comments:

- It would be nice if the specification tracked the list of modes
   per output.  Rather than have a single list of modes for the X screen,
   and then have each output reference whichever modes are valid for that
   output, it may make more sense to just store the modes per output.
   One advantage is that the user can request a mode named "auto-select",
   and each output could have a different mode with that name.  We've had
   this in the NVIDIA driver for a while, and it's been very useful.
   The NVIDIA X driver also ensures that each mode in the per-output
   list has a unique name, so that each mode can be uniquely requested
   through the existing X config file.  There is some info on that in
   this section of the NVIDIA README:

     http://download.nvidia.com/XFree86/Linux-x86/1.0-9629/README/appendix-j.html

   I suppose that if you ever wanted to associate additional properties
   with modes, but if those properties should be different per output,
   then storing the modes per output would make this easier.

   The downside of per-output modelists is that you end up with some
   duplication of modes that are valid for each output.  I wouldn't
   consider that a big deal, though.

   I think to support that, the spec would need to be changed to move the
   LISTofMODEINFO out of the RRGetScreenResources and into RRGetOutputInfo.
   RRCreateMode and RRDestroyMode would need to take an OUTPUT, and then
   RRAddOutputMode and RRDeleteOutputMode would be unneeded.

   If that sounds reasonable, I could make the spec changes.


- The proposed spec lets the client separately configure the X screen
   size and each CRTC.  This has very nice flexibility in that each piece
   can be separately controlled.

   One minor downside is that it takes multiple requests to reconfigure
   things, and if one request fails, then the client may need to unravel
   the previous requests to restore the X server to the previous state.
   (that's in the best case where the client is actually coded to handle
   that failure case; likely that clients would punt and then it would
   be up to the user to get things back to the original state)

   One major downside is that this doesn't give an implementation a
   good opportunity to perform validation of the complete system.
   The CRTC vs output distinction expose some specific hardware
   capabilities/limitations to the client.  That's fine, except that
   there may be other restrictions.  For example, things like video memory
   bandwidth or TMDS Links may limit the combinations of modes that you
   can use on different outputs at the same time.

   Exposing CRTC vs output in the spec seems OK, but seems insufficient
   to reflect all hardware restrictions; and I think hardware changes
   too rapidly to realistically reflect all the various limitations that
   hardware might have.

   For our research into display configuration in the NVIDIA driver,
   we've used the idea of a MetaMode as a container of an X screen's
   configuration: X screen size, per-output mode, mode positioning,
   panning, etc.  A client can use NV-CONTROL protocol to dynamically
   add new MetaModes to an X screen (the X screen contains a list of
   MetaModes); then, the client separately switches which MetaMode the
   X screen should use.

   This is nice because adding a new MetaMode gives the implementation
   a central place to perform any needed validation, and then you have
   a higher likelihood of later being able to fullfill the request to
   switch to that MetaMode.  A MetaMode is also a nice abstraction for
   backwards compatibility with RandR 1.1 and XF86VidMode -- they just
   see the MetaMode as a single mode.  Lastly, keeping multiple complete
   screen configurations around makes it easy to return to the previous
   config, if the user wants to revert his changes (or you present an
   "are these new settings OK?" dialog with a 10 second timeout).

   I've included some pointers at the end of this email, in case you're
   interested in poking around more with the NV-CONTROL API for this stuff.

   I know it's late in the RandR 1.2 design to suggest such a drastic
   change, but to adjust RandR 1.2 to take more of a "MetaMode" approach,
   the needed changes would probably be:

     - add requests to add/remove a "ScreenConfiguration" (or call it a
       "MetaMode", or whatever); a ScreenConfiguration would likely contain
       the arguments that are current passed to the RRSetScreenSize and
       RRSetCrtcConfig requests.

     - add a request to change the current ScreenConfiguration

     - remove the RRSetCrtcConfig and RRSetScreenSize requests

   If that sounds interesting, atleast to see what the spec would look
   like with those changes, I could make the spec changes.  I'd also
   volunteer to help with the implementation effort.


- Other minor stuff:

     - Should DPI be queriable per-output; I know the core X protocol
       provides a single WidthMM, HeightMM per X screen, but it might be
       useful to allow aware applications to query the DPI with per-output
       granularity.

     - The spec should probably be clear that just because the width/height
       in a RRSetScreenSize request is within the min/max range reported by
       RRGetScreenSizeRange, we're not guaranteed to be able to fullfill
       that.  Video memory constraints, or other hardware constraints may
       come into play that cannot be reflected completely by the min/max
       values reported by RRGetScreenSizeRange (I assume that range is
       intended to report the maximum renderable sizes?)

     - I believe TwinView/MergedFB is different than Xinerama, and
       that they solve slightly different problems.  RandR 1.2 solves
       the problem of querying/configuring outputs on an X screen on a
       single GPU.  But having a Xinerama X screen across multiple GPUs
       is slightly different -- if each GPU stores only a portion of the
       entire Xinerama X screen, the outputs connected to that GPU are
       limited in which portions of the Xinerama X screen they can display.

       (I know there are plenty of implementation concerns with Xinerama:
       duplicated pixmaps on each physical X screen, etc; hopefully those
       issues are independent of the XRandR+Xinerama issues discussed
       here).

       This is a post-1.2 RandR issue, but my vote would be to expose
       the underlying physical X screens through RandR when Xinerama
       is enabled.

     - Should a future version of the RandR spec allow clients to talk
       in terms of the physical X screens underlying a Xinerama X screen?
       If so, then perhaps the requests

         RRGetScreenSizeRange
         RRSetScreenSize
         RRGetScreenResources
         RRCreateMode

       should take a screen index, rather than a WINDOW?  I assume in
       Xinerama there is one Window for the entire Xinerama X screen,
       whereas we may want finer granularity in the future?


NV-CONTROL pointers

Here are some NV-CONTROL pointers, in case it's interesting to see the
API that we used in the NVIDIA driver.

For talking about MetaModes and ModeLines, the NV-CONTROL extension uses
strings since they're very flexible.  But defined data structures are
more concrete and probably better for RandR.

There is some info on the NVIDIA driver's mode validation here:

     http://download.nvidia.com/XFree86/Linux-x86/1.0-9629/README/appendix-j.html

and some info on the NVIDIA driver's MetaMode syntax here:

     http://download.nvidia.com/XFree86/Linux-x86/1.0-9629/README/appendix-g.html

If you grab the NVIDIA Linux control panel source here:

     ftp://download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-1.0.tar.gz

The relevant string attributes are documented in the header file:

     nvidia-settings-1.0/src/libXNVCtrl/NVCtrl.h

The relevant string attributes are:

         NV_CTRL_STRING_CURRENT_MODELINE
         NV_CTRL_STRING_ADD_MODELINE
         NV_CTRL_STRING_DELETE_MODELINE
         NV_CTRL_BINARY_DATA_MODELINES

         NV_CTRL_STRING_CURRENT_METAMODE
         NV_CTRL_STRING_ADD_METAMODE
         NV_CTRL_STRING_DELETE_METAMODE
         NV_CTRL_STRING_MOVE_METAMODE
         NV_CTRL_BINARY_DATA_METAMODES
         NV_CTRL_STRING_OPERATION_ADD_METAMODE


Thanks,
- Andy