[RFC PATCH] Add XI_PROP_ROTATION property to the server's properties.

[Simon Thum]

On 03/23/2011 06:13 AM, Peter Hutterer wrote:
> Having rotation support has been a feature requested for a while
> now. Now we've had two independent implementations happen within quite a
> short timeframe, one in synaptics, one in evdev (and wacom has had it's own
> implementation for a while). So the question is now, how to do this best.
> 
> We have the transformation matrix in the server which can be used to rotate
> absolute devices. But it's not yet suited for relative devices and I'm not
> 100% sure it's a trivial task to do so.
> 
> The alternative is a separate transformation property. To unify this, I'd
> like to see this property defined by the server (but not necessarily
> implemented by the server). Since different devices have different
> requirements (e.g. synaptics may only allow rotation in 90 deg angles) it
> seems best implemented by the driver.
> 
> Of course, the exact semantics of where this property fits in have to be
> documented to avoid nasty surprises, but that'll happen in the final version
> of this patch then.
> 
> Does that make sense?
I'll try to bridge my reasons for a matrix as we already have and the
things that come up in addition.

The IMO most important aspect about affine transforms is that they're
affine. That is, whatever aspect you want to be represented in a matrix
you can create a matrix that incorporates it and arbitrary other
(linear) things.

So e.g. in VRML/X3D transforms, you'll essentially create transforms out
of translation, rotation and scaling and chain them up to set the stage.

That could work equally well for the case you're making.

Each "aspect" (such as the rotation property you're describing) would
need to be assigned its place in the transformation chain. Unset/unused
aspects essentially have a unity matrix in place.

Each time one of the matrices changes, you can again squash them into
one (or more, depending on which intermediate results you actually need)
matrix and just use that. It would be read-only to the outside world or
not even visible. Nonetheless, the current transform matrix could be one
of its components, allowing all kinds of modifications.

An implementation could be a linked list of transforms for each chain
(e.g. driver CS to input CS, input CS to protocol CS, protocol to
on-output-screen CS). The crucial point is that each aspect is an item
in the list, and you're only ever using the end result to actually
transform coordinates, guaranteeing constant time independent of who
want what[0] to happen. Of course, the chains would be per-device,
per-output, per-*.

That may sound a bit pie-in-the-sky, but AFAIK, pixman already has in
place the bits that what would be required. That's not saying it's a
cakewalk, but definitively feasible. It would perhaps also have the
benefit of making it obvious which code deals with what CS.

The hardest part may be applying the matrix onto the relative part, BUT:
It's not hard once you get rid of the int+fractional thing that is just
a relic of the past anyway. You'll just have to make sure the relative
path uses a 2x2 sub-matrix. It can't be _that_ hard. Without further
looking at pixman, this sounds like something it could do already.

Cheers,

Simon


[0] With the exception of non-linear stuff such as pointer acceleration.
Non-linear and frequently changing transforms would still best be done
in code I guess.

> 
> ---
>  Xi/xiproperty.c              |    3 ++-
>  include/xserver-properties.h |    7 +++++++
>  2 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
> index 83ce930..61b1fdc 100644
> --- a/Xi/xiproperty.c
> +++ b/Xi/xiproperty.c
> @@ -179,7 +179,8 @@ static struct dev_properties
>      {0, BTN_LABEL_PROP_BTN_GEAR_DOWN},
>      {0, BTN_LABEL_PROP_BTN_GEAR_UP},
>  
> -    {0, XI_PROP_TRANSFORM}
> +    {0, XI_PROP_TRANSFORM},
> +    {0, XI_PROP_ROTATION},
>  };
>  
>  static long XIPropHandlerID = 1;
> diff --git a/include/xserver-properties.h b/include/xserver-properties.h
> index c6259ae..cd95a61 100644
> --- a/include/xserver-properties.h
> +++ b/include/xserver-properties.h
> @@ -42,6 +42,13 @@
>   * [c6 c7 c8]   [1] */
>  #define XI_PROP_TRANSFORM "Coordinate Transformation Matrix"
>  
> +/* CARD32, 1 value
> + *
> + * Device rotation in 1/10 of a degree. Range 0...3600. This property is
> + * implemented by the driver, and may have additional restrictions.
> + */
> +#define XI_PROP_ROTATION "Device Rotation"
> +
>  /* Pointer acceleration properties */
>  /* INTEGER of any format */
>  #define ACCEL_PROP_PROFILE_NUMBER "Device Accel Profile"