On 03/30/2012 12:37 PM, Ville Syrjälä 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.
Exactly, and I would prefer a separate rotation (0,90,180,270) and
mirror (true,false) property. I see no reason to merge these using a
special bitmask property type.
And if there is an issue with atomic commit of rotation and mirror, this
does not solve the general atomic commit issue. And if we solve that, we
don't need to merge two properties in one.
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.
+1, I think a general mechanism for standard properties would be helpful
for applications that want to expose a dynamic interface with settings
supplied from kernel.
Option A would be easy to add, but option B would make it easy to do
atomic commit with normal params and properties (as described in
previous email). So why not A+B? Add ids to make setting multiple
properties easier and add a name prefix. I assume these property names
are IDs and not something intended to be shown to the user directly
(i18n). And having standard property names would allow UI to include
translations for these properties. Non standard properties could just be
shown using their ID.
/BR
/Marcus
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
