RandR 1.3 additions?
Matthias Hopf
mhopf at suse.de
Tue Jan 22 09:00:50 PST 2008
On Jan 22, 08 08:45:56 -0800, Keith Packard wrote:
> + "RANDR_SIGNAL_FORMAT" aka RR_PROPERTY_SIGNAL_FORMAT
> + Type: int8
> + Flags: Immutable (TBD)
>
> This should be allowed to be mutable, but not required -- at least the
> Intel TV output can switch formats.
The signal format has to be specifiable in some cases (e.g. TV), I just
wasn't sure whether it would be the best idea to make this propery
mutable or not. If it is mutable it should be made clear that only the
subtype can be changed (e.g. you cannot change from TMDS to SVideo)
and the driver may reject it.
> (btw, in the US, we use 'composite', 's-video' and 'component' instead
> of FBAS,SVideo and YPbPr)
Names are all debatable :-)
composite: fine with me (though FBAS is AFAIK the technical term)
s-video: fine as well (though '-' is currently used as separator)
component: hm. this is probably easier understood, though YPbPr is the
technical term, and describes the used color space better.
So I'm fine with using these names instead of my selection, depending on
how others see it.
But in the case of s-video we have to use a different separator for
subtypes - is '/' reasonable enough? So that would e.g. result in
composite/PAL. Also, the same separator should be used in the other
properties.
> + "RANDR_PANNING_AREA" aka RR_PROPERTY_PANNING_AREA
> + Type: string
> + Flags: -
> + Format: <width>x<height>[+<xoffset>+<yoffset>]
>
> We should do this with protocol instead of a property.
Well, radeonhd proofs that a property is enough here - it works already
pretty well (except for some glitches due to xrandr resetting the
framebuffer size on typical invocations).
So I don't see the necessity for a protocol change, but I'm open minded
here.
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
More information about the xorg
mailing list