[RFC] RandR 1.3 properties
mhopf at suse.de
Fri Nov 7 08:18:23 PST 2008
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
Matthias Hopf <mhopf at suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat at mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
More information about the xorg