Re: [RFC PATCH] Add XI_PROP_ROTATION property to the server's properties.
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
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH] Add XI_PROP_ROTATION property to the server's properties.
On Wed, 23 Mar 2011 15:48:39 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: you already need a client to toggle the CRTC rotation, why not let that client toggle input device rotation as needed? having those two hooked up in the server it just seems like headache. Note that per-crtc pixmaps decouples the X server from rotation, so it won't know to flip the input anyways. -- keith.pack...@intel.com pgpSeB3wQS4Yn.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH] Add XI_PROP_ROTATION property to the server's properties.
On Wed, 23 Mar 2011 15:55:14 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Mar 23, 2011 at 02:37:40PM +0900, Keith Packard wrote: On Wed, 23 Mar 2011 15:13:55 +1000, Peter Hutterer peter.hutte...@who-t.net 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. How does this relate to the RandR 1.4 sprite transforms? If I understand the randrproto correctly, randr sprite transform happen after the input device rotation and are somewhat connected to the CRTC transformation. Right, the sprite is transformed (image and position) by a projective matrix provided by the application for presentation on the specified CRTC. It is designed solely to provide the required transform for compositing-manager native rotation support. Do they solve the case of this hardware has a sensor offset of 36 degrees counterclockwise, so we need to rotate any input by this amount? They don't transform the reported coordinates, only the presentation of the sprite. -- keith.pack...@intel.com pgp6NOlhZyNWx.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH] Add XI_PROP_ROTATION property to the server's properties.
Peter == Peter Hutterer peter.hutte...@who-t.net writes: Hi, Peter Having rotation support has been a feature requested for a while Peter now. Now we've had two independent implementations happen within Peter quite a short timeframe, one in synaptics, one in evdev (and Peter wacom has had it's own implementation for a while). So the Peter question is now, how to do this best. Peter We have the transformation matrix in the server which can be Peter used to rotate absolute devices. But it's not yet suited for Peter relative devices and I'm not 100% sure it's a trivial task to do Peter so. Why is that? I haven't looked, but I would expect you could just handle relative motion as a 2d vector, and apply the transformation to it. Peter The alternative is a separate transformation property. To unify Peter this, I'd like to see this property defined by the server (but Peter not necessarily implemented by the server). Since different Peter devices have different requirements (e.g. synaptics may only Peter allow rotation in 90 deg angles) it seems best implemented by Peter the driver. Using the existing matrix seems to me like the cleanest approach. I know it is a bit more complicated than a single rotation angle, but this extra complexity also brings more features (E.G. the offset/scaling stuff needed for absolute devices in multihead setups). I don't get what you mean about synaptics only allowing 90 deg angles rotation - Isn't rotation purely a software feature? -- Bye, Peter Korsgaard ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH] Add XI_PROP_ROTATION property to the server's properties.
Hi, Thinking out loud ... On Wed, Mar 23, 2011 at 03:13:55PM +1000, 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 had in mind two properties: a CRTC ID which would bind the input device to the given CRTC (so, for absolute devices, map the area to the CRTC area), and another bool which would follow that CRTC's transform. So, if you had a touchscreen, you could just give it an absolute CRTC binding and have it always follow the CRTC's transform to get rotated co-ords, etc. We might still need an explicit rotation property though. But yeah. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH] Add XI_PROP_ROTATION property to the server's properties.
On Wed, 23 Mar 2011 15:13:55 +1000, Peter Hutterer peter.hutte...@who-t.net 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. How does this relate to the RandR 1.4 sprite transforms? -- keith.pack...@intel.com pgpH0FD9JwZQj.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH] Add XI_PROP_ROTATION property to the server's properties.
On Tue, Mar 22, 2011 at 10:37:22PM -0700, Daniel Stone wrote: Hi, Thinking out loud ... On Wed, Mar 23, 2011 at 03:13:55PM +1000, 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 had in mind two properties: a CRTC ID which would bind the input device to the given CRTC (so, for absolute devices, map the area to the CRTC area), and another bool which would follow that CRTC's transform. So, if you had a touchscreen, you could just give it an absolute CRTC binding and have it always follow the CRTC's transform to get rotated co-ords, etc. We might still need an explicit rotation property though. But yeah. you already need a client to toggle the CRTC rotation, why not let that client toggle input device rotation as needed? having those two hooked up in the server it just seems like headache. e.g. i may have a wacom tablet I use upside down (to have the buttons on the right side of the tablet). what happens when I rotate my screen now? does it rotate my tablet to be 90 degrees? not sure that's what I want. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH] Add XI_PROP_ROTATION property to the server's properties.
On Wed, Mar 23, 2011 at 02:37:40PM +0900, Keith Packard wrote: On Wed, 23 Mar 2011 15:13:55 +1000, Peter Hutterer peter.hutte...@who-t.net 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. How does this relate to the RandR 1.4 sprite transforms? If I understand the randrproto correctly, randr sprite transform happen after the input device rotation and are somewhat connected to the CRTC transformation. Do they solve the case of this hardware has a sensor offset of 36 degrees counterclockwise, so we need to rotate any input by this amount? Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
