On Wed, Mar 23, 2011 at 11:18:17PM +0100, Peter Korsgaard wrote: > >>>>> "Peter" == Peter Hutterer <[email protected]> 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.
i tried to find the patches when I attempted it but now all I remember is that I couldn't get it to work easily. so something was missing. > 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? yes, of course. it's more that the driver arguably shouldn't allow non-90 degree rotations. but then again, you could argue that telling a user not to shoot themselves in the foot is enough, we don't need to take their gun away. Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
