[RFC] RandR 1.3 properties

[Matthias Hopf]

On Oct 28, 08 14:37:30 -0700, Keith Packard wrote:
> On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote:
> > - Apparently there are only 8, 16, and 32bit integers available as
> >   property types. Having ATOMs and FLOATs would add semantics, which
> >   could help in some cases. But if this implies some changes throughout
> >   the system, I don't think this is helpful. If it's basically xrandr,
> >   it would be easy.
> 
> ATOMs are obviously supported, but FLOATs seem harder as they aren't
> described in the core protocol anywhere.

Thinking about that, adding floats was probably a bull idea. However,
having semantics about ATOMs might be helpful (e.g. for xrandr or any
general purpose property setting tool).

> For the TV signalling type, I think we'll need more options; PAL has a
> lot of variants that we'll want to expose. I'm also thinking we want to
> expose a separate TV signalling property and leave the general property
> as 'TV' or some such.

Reasonable. Thinking about that.
Types of PAL are typically PAL-B, -G, -H, -I, -M, -D, -N, -Nc
Similar for NTSC and SECAM. Any additional features?

Actually, single link/dual link, number of DisplayPort links, etc. could
be set in the same property.

Adding this as SignalProperties.

> > - Panning - Keith indicated pretty strongly that this should be part of
> >   the protocol level, and not a property. Haven't dealt with that yet,
> >   it's still in the diff.
> 
> Yeah, we'll need stacks of code to manage this property, so it's not
> just informational like most of the other properties.

Agreed. Thinking about that. Find a protocol suggestion in the next
diff.

Matthias

-- 
Matthias Hopf <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de