On Fri, Mar 30, 2012 at 5:37 AM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > 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. well, I'd sort of prefer not having two levels of translating rotation bitmask into something else (ie. userspace xrandr -> kms, then kernel kms -> hw).. so I'd prefer to stick to xrandr bitmasks rather than just shuffle some bits around for the sake of it.. the only advantage I like with x-invert/y-invert/xy-flip is that it doesn't have invalid bitmask combinations (ie. RR_Rotate_0 | RR_Rotate_90) > > 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. yeah, basically this was why I was bouncing the idea of rotation related properties off the list.. I'd rather use values in omapdrm that we could align on for other drivers BR, -R > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
