[RFC] RandR 1.3 properties
mhopf at suse.de
Tue Oct 28 11:51:39 PDT 2008
This is a second try to establish a request for comments on the standard
properties of the upcoming RandR 1.3.
The first try died out pretty quickly, also due to /me being a lazy
bastard (read: other projects took away all of my time).
I finally updated the draft, as my original version wasn't exactly
future proof. The current version should work with both naming schemes
for outputs (connectors vs. encoders)
Of course, everything is open for discussion, but there are some
additional points I'd like to point out that need more thoughts:
- 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.
- Is RANDR_BANDWIDTH helpful? Or should we have a dedicated property for
indicating dual link capability on DVI? What other meta information
(also on other connections) would be useful?
- Should RANDR_CONNECTOR_TYPE be made mandatory?
If a driver *really* doesn't want to implement anything here, it could
always set this to '0' and be done.
- 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.
- So far we didn't have standard properties, and no RANDR_ prefix.
EDID_DATA had been around since 1.2, should that be renamed to
RANDR_EDID_DATA (as indidcated in the draft), be left alone (and the
whole RANDR_ prefix idea burried), or cloned?
Matthias Hopf <mhopf at suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat at mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8243 bytes
Desc: not available
More information about the xorg