On Thu, Mar 29, 2012 at 08:15:48PM -0500, Rob Clark wrote: > On Thu, Mar 29, 2012 at 8:02 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote: > > From: Rob Clark <rob@xxxxxx> > > > > A bitmask property is similar to an enum. The enum value is a bit > > position (0-63), and valid property values consist of a mask of > > zero or more of (1 << enum_val[n]). > > > > TODO: word commit msg better > > TODO: maybe "flags" would be a better name for the property type? > > --- > > See https://github.com/robclark/kernel-omap4/commit/970b7bb95993fc43b4977976bf8005dc2e1a4ad3#L6R411 > > for an example usage. In this case combinations of "x-invert", "y-invert" > > and "xy-flip" can express all possible combinations of rotations of > > multiples of 90 degrees plus mirroring. Which is sufficient for an > > xrandr v1.2 rotation support. For arbitrary transforms in xrandr v1.3 > > a different property with a transform matrix (if supported by the > > driver) should be used. > > oh, and this shows the mapping between xrandr rotation/reflection mask > and x-invert/y-invert/xy-flip: > https://github.com/robclark/xf86-video-omap/commit/87ffbaf9d282831bf03da457e6f6c4e45a0d6b2b#L0R222 > > The other option is of course to make the rotation bitmask mirror the > xrandr rotation mask values, which might be a better option to support > drivers which only provide rotation and not mirroring. I'm ok with > either option, whatever others prefer. I would prefer something like that, but we shouldn't just blindly copy the exact bit definitions. The xrandr reflection vs. rotation always seemed to be backwards to me. To me it feels more natural to first rotate, and then reflect/mirror. But it could be that I've just been influenced by specific hardware designs. Now that there seems to be a spur of activity in the property area, could we come up with some way to better control what properties get added, and how they're defined. Currently every driver is free to define whatever ad-hoc properties they wish. I would suggest we either A) define some namespace for standard properties, or B) introduce some new property mechanism that actually uses integer property IDs. In either case new properties or changes to existing standard properties should be carefully reviewed. I'm sort of partial to option B, since doing a gazillion string comparisons when pushing lots of properties to the driver seems like a pointless waste of cycles. OTOH option A seems a little less revolutionary. In any case, the current mess just doesn't allow any kind of truly generic user space code to be written. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
