[PATCH RFC 1/2] drm: add bitmask property type
rob.clark at linaro.org
Fri Mar 30 05:25:34 PDT 2012
On Fri, Mar 30, 2012 at 5:37 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> 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 at linaro.org> wrote:
>> > From: Rob Clark <rob at ti.com>
>> > 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:
>> 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
> 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 at lists.freedesktop.org
More information about the dri-devel