RandR 1.2 feedback

[Keith Packard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20061129/01d48a3a/attachment.pgp>