[PATCH RFC 1/2] drm: add bitmask property type

[Rob Clark]

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:
>> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel