On Tue, Oct 28, 2008 at 10:37 PM, Keith Packard <[EMAIL PROTECTED]> 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. > >> - 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? > > I think it would be better to just indicate that this is a dual-link > connector. > >> - 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. > > Yes, we should make several of these required. I'm wondering how well we > can do in automatically setting these from BIOS properties in the Intel > driver though. > > 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. > >> - 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. > >> - 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? > > I'd say that we should feel free to take over the unprefixed name space, > but that we should explicitly call out property names starting with '_' > as non-standard properties. > > -- > [EMAIL PROTECTED] > > _______________________________________________ > xorg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xorg >
Is there any chance to get rid of strings in the protocol/server altogether and stick to standardised "names" and properties (in the form of enums) as much as possible? It would improve consistency for the standard stuff a lot. _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
