RandR 1.2 output properties and options

[Keith Packard]

Output devices occasionally need more information than is provided in
the mode line to correctly program the hardware. LVDS panels need
scaling information, TV outputs need all kinds of data. Most of these
options don't affect whether the modeline can be supported by the
hardware, rather they affect what the hardware will do with a specific
modeline. As such, they need to be separate from the modeline and
associated only with the output.

The first plan was to create a set of 'options' associated with each
output in the configuration request. That might have worked for simple
boolean options (like whether to do panel scaling or not), but falls
down when you have options like contrast/hue controls or other complex
valued options.

In addition, outputs have options (like color controls) which can be
adjusted while the modeline is active. It doesn't make sense to reset
the configuration just to adjust simple output parameters like this.

Independently, we created this notion of 'output properties' which were
designed communicate information about the hardware to (and potentially
from) applications. A simple example here is the EDID data -- the output
device will set the EDID property to report to applications the data
provided by the monitor about its capabilities. Taking that the other
direction, an application may decided to override that EDID data and
supply its own. In doing so, the X server will recalculate the list of
supported modes and present that in the other parts of the RandR
protocol. With this notion that two-way communication was possible
through properties, we decided to try and extend properties to support
the values formerly transmitted through the option mechanism.

One problem with the property mechanism is that, unlike options, there
was no explicit time at which the property would take effect. Options
were provided as a part of the mode setting operation, properties were
set separately.

In addition, the valid range of property settings isn't explictly
provided in the protocol while the valid option settings were. Not
knowing what possible values a property might take makes it impossible
for applications to accurately present them to the user.

I think we need to make properties more complicated to cover these two
requirements, at which point they will be able to cover the features
present in the options mechanism while continuing to satisfy existing
use cases.

So, I think properties need to contain several fields:

      * Current value. This is what the hardware is currently using.
      * Pending value. This is what the hardware will use the next time
        it is configured.
      * Range of valid values. For ordered sets, this can just be a
        simple pair of minimum/maximum limits for the value. For
        unordered sets, we need a list of valid values.
      * Type. Just like window properties, the representation and type
        are separate, permitting some more accurate type checking.
      * Name. An atom representing the intended use for the property.

This raises some interesting questions -- who gets to set the range of
valid values? Can you set and query the pending value separately from
the current value?

I suggest that values controlled by the X server should have a read-only
range of values. Values created by applications may have a range of
valid values as well, but the range can be set by applications.

For properties which have no pending/current split, they will report
only the current value. I think I will mix the notion of pending/current
with the range setting request so applications can create new properties
that work like the built-in properties.

-- 
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/20061117/3fe4fc50/attachment.pgp>