RandR 1.2 feedback

[Andy Ritger]

Thanks, Keith.  Fair enough.

I think we'll just have to agree to disagree on some of these points.

I think the RandR 1.2 spec is workable as-is, so I'll just plan on going
with that.  I'll look at wiring up the NVIDIA driver to RandR 1.2.

Just a few comments:

> Let's solve the problems we know about and worry about fixing future
> problems when the occur. I've often created systems that were overly
> complex when attempting to guess what future environments would look
> like.

Understood; I was just looking for ways to make this more future proof.  I
had hoped that giving the implementation a more general place to validate
the configuration, given a complete description of the user-requested
configuration, would cover any unforeseen future constraints.  But let's
go with the incremental approach and see how it goes.

>> That sounds perfect.  However, when I went through the spec, I didn't
>> see mm_width/mm_height values in the outputs.  I see mm width/height in:
>
> Check out the GetOutputInfo request.

Sorry, I was looking at the version of the spec in
'users/keithp/randrproto', rather than in 'xorg/proto/randrproto'.
Now that I'm looking at the right version of the spec, I see what you're
talking about.  Looks great.

> I think the biggest issue here is how to make direct rendering work
> right, something the current Xinerama implementation just doesn't
> support at all. I think we can both agree that getting 3D working in a
> multi-screen environment is a rather important part of the puzzle.

I agree with your earlier points that Xinerama vs RandR is an
implementation issue rather than a spec issue (mostly -- I think you
earlier noted that perhaps RandR should also expose the topology of
outputs connected to which GPUs; I agree with that).  It also seems
that most of Xinerama is the implementation issues (it's not like the
Xinerama specification is very interesting).

However, note that NVIDIA's OpenGL implementation works fine within
Xinerama today.  I don't believe the current Xinerama implementation in
the X server precludes direct rendering OpenGL.  Any problems we've had
implementing OpenGL within the current Xinerama implementation have
really been problems with our OpenGL implementation, rather than problems
interacting with the Xinerama implementation.

Anyway, it sounds like there is a lot of interesting stuff to discuss
wrt the Xinerama implementation and how to either replace or improve that.
I'll leave the topic alone for now so we can focus on RandR 1.2.

Thanks again for the feedback,
- Andy



On Wed, 29 Nov 2006, Keith Packard wrote:

> On Wed, 2006-11-29 at 01:20 -0800, Andy Ritger wrote:
>
>> That's a good point about clone mode not making per-output modes feasible.
>> Perhaps the modes should be per-CRTC, but not a big deal.  The per-screen
>> mode list is workable, so I'll leave that topic alone.
>
> Yeah, except I can move outputs between CRTCs. Mostly.
>
>> I suppose the limits would be anything that is a shared resource between
>> the CRTCs.  Memory bandwidth is the only good example that comes to mind:
>> if the memory subsystem of the graphics hardware has constraints such
>> that it cannot feed all CRTCs simultaneously when all CRTCs run at
>> their maximum clks, then that's a limit that cannot be validated just
>> by looking at the mode on one output by itself.  Granted, that's not a
>> likely scenario.  I'm more concerned about the system contraints that
>> we can't foresee today.
>
> Let's solve the problems we know about and worry about fixing future
> problems when the occur. I've often created systems that were overly
> complex when attempting to guess what future environments would look
> like.
>
>>> And, encapsulating the configuration in a container data structure
>>> doesn't really solve the problem; you still have no way of describing
>>> "why" a configuration can't be used.
>>
>> Yes, the "why" feedback is missing, but providing the feedback seems
>> like a separate issue than identifying that the currently requested
>> configuration cannot be fulfilled.
>>
>> Is it better for the client to
>>
>>      - resize the root window
>>      - set a mode on output A
>>      - set a mode on output B
>>
>> but have the output B mode fail because there is some conflict with what
>> is already setup on output A, or have the client say, "I'd like to
>> register a configuration that has:
>>
>>      - a particular sized root window,
>>      - a particular mode on output A, and
>>      - a particular mode on output B"
>>
>> and have the registering of that configuration fail?
>
> I don't see these as any different; the desired configuration is not
> reachable, so the user will need to figure out why. If we could provide
> reasonable feedback, the user might have a chance of fixing things,
> independent of how the system is configured.
>
> To some extent, I would like to see the notion of global configuration
> left to the client while the server just provides the necessary
> primitives. The metamode notion was necessary when there wasn't any
> other way to expose the hardware capabilities over the wire in a
> standard fashion. With a standard mechanism, we can punt all of the UI
> issues across the wire.
>
> I have already started fixing the 'xrandr' app to do some global
> configuration, like 'put me in clone mode everywhere' and 'put me in
> panorama mode'. For most uses, I suspect those simple requests will
> suffice. For more complex setups, we're going to need a GUI to lay the
> monitors out across the screen anyway, at which point any discussion
> about 'meta modes' is moot. Just as we don't use color names to describe
> colors any longer (unless you're a pantone nut), now that we have color
> pickers, I suggest the same should be true of screen configuration, once
> we have a GUI, named configurations become a lot less interesting.
>
>> Oh, sorry, I was suggesting to replace the incremental assignments by a
>> single atomic assignment, giving the implementation a central place to
>> perform its validation.
>
> Right, I understood your plan, I just don't think it's a necessary
> change. I like the incremental approach because each request has
> reasonably simple semantics and encoding, plus error states can be more
> easily understood. The 'one big reconfigure' request leaves the user
> with even less feedback about why the configuration cannot be supported.
>
> Plus, a GUI relayout tool really shouldn't need to create and destroy
> objects just to move monitors around.
>
>> My concern is that each incremental step requires reconfiguration and
>> revalidation, such that each incremental step is a potential point
>> of failure.
>
> It's the same work as doing the global configuration, except the driver
> now has to be able to answer the question about whether a configuration
> can be supported separately from responding to the configuration
> setting. Assuming that two code paths will always remain in perfect
> agreement about what can be supported is an error-prone design.
>
>> That sounds perfect.  However, when I went through the spec, I didn't
>> see mm_width/mm_height values in the outputs.  I see mm width/height in:
>
> Check out the GetOutputInfo request.
>
>> Also, does mm_width/mm_height make sense in the MODEINFO?  Isn't the
>> physical size a function of mode+output?  The same mode could have
>> drastically different physical size on different outputs.
>
> Outputs can change their physical size in response to a mode change. I
> actually removed physical size information from a mode as it does depend
> on the target output. So, you can't know before setting the mode what
> the physical size will be, but after the mode is set, you will find out
> what the size is. I think that's sufficient.
>
>> OK.  I'll leave this topic alone for the short term, since it seems it
>> will be a contentious issue.  Definitely not something for RandR 1.2;
>> I was just trying to identify if the 1.2 spec would limit multi-GPU X
>> screens in a future version of the RandR spec.
>
> It's not a spec issue, it's an implementation issue. RandR 1.2 can
> support multiple screens, each with multiple monitors, so a multi-card
> environment could actually support the hardware exactly as it operates.
> We can also fix the implementation so that it uses the existing
> DIX-level code to make it support a single screen across multiple GPUs.
> That's just internal X server code manipulation, nothing exposed in the
> protocol.
>
>> X screens spanning GPUs is a hot topic for NVIDIA customers, so I'll
>> try to pick this up.  Maybe I can organize an XDevConf '07 talk on this.
>
> Yeah, I understand the requirements. The 'best' solution will require
> some dramatic surgery inside the X server to avoid the current DIX-level
> Xinerama performance problems.
>
> I think the biggest issue here is how to make direct rendering work
> right, something the current Xinerama implementation just doesn't
> support at all. I think we can both agree that getting 3D working in a
> multi-screen environment is a rather important part of the puzzle.
>
>> I'll have to do a bit more research into the existing preferred modes
>> mechanism, but I think the current per-screen modelist is workable.
>
> Ok, cool. If we need to, I think we can use the output property
> mechanism for an 'auto-select' mode mechanism. In particular, I'm
> thinking that the 'default' mode for a screen should prefer modes which
> result in a DPI near 96, unless the monitor has a preferred mode. I'll
> be coding that up in my driver-independent configuration logic.
>
>> Hopefully I've clarified the MetaMode stuff.
>
> I think I understood the MetaMode stuff fairly well, I just didn't
> really explain why I didn't think it was useful in the RandR 1.2
> environment. I suggest there are two fundemental reasons:
>
>     1. One code path is better than two. Splitting the configuration
>        creation from the configuration application means that the
>        driver has to separately validate possible configurations and
>        then, at some future time, apply them to the hardware.
>     2. GUI-based configuration tools are all about showing the user
>        changes immediately. In this environment, there isn't any
>        'label' to apply to the configuration as it is being
>        constructed. Errors in this environment really do apply
>        precisely to the action the user just performed, which with the
>        incremental protocol are easy to explain.
>
>>> A similar mechanism to deal
>>> with video-mode switching games would also be useful.
>>
>> What do you mean by that?  What does an RandR 1.2 implementation look
>> like to a video-mode switching games using XF86VidMode or RandR 1.1?
>
> (I'm planning on replacing the XF86VidMode implementation with a
> DIX-level version using RandR 1.2 driver functionality.)
>
> One of the problems with XF86VidMode is that when applications
> terminate, the screen configuration is left as it was. It would be
> nicer, in most cases, to have the configuration revert to the previous
> setup instead.
>
>> Does such a client effectively just see the mode on the "first" output?
>> The MetaMode approach makes the entire screen configuration look like
>> one mode to XF86VidMode or RandR 1.1 clients.
>
> We can do whatever we like, but right now RandR 1.1 and XF86VidMode
> clients see only the first monitor. This seems correct for XF86VidMode
> applications; they want to set a monitor to a particular resolution for
> fixed-resolution games (usually). For RandR 1.1, I expect those
> applications to migrate to RandR 1.2 fairly quickly; there aren't very
> many of them (mostly desktop configuration tools).
>
> I'm certainly not interested in complex mechanisms that exist solely to
> provide for backward compatibility with a few existing applications.
> Ick.
>
> -- 
> keith.packard at intel.com
>