Request for comments on zts rotational scaling issue

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Request for comments on zts rotational scaling issue

asmith-4
There is an issue with running the Zaurus touch screen driver in portrait mode in X.

The issue is as follows.

The zts driver provides /dev/wsmouse as standard and this is accessed through the ws_drv.so mouse driver.

A USB Mouse will connect on the Zaurus as /dev/wsmouse1 which will also be accessed through the ws_drv.so driver.

The zts driver requires a certain amount of calibration and internally handles scalinig factors for X and Y co-ordinates. In the standard mode of operation the ws driver through zts handles the mouse in Landscape mode.

When the wsfb_drv.so screen driver is placed into portrait mode it starts to translate mouse co-ordinates to a 90 degree rotation (or 270 degree if placed in inverse portrait mode). To accomplish this it starts to manipulate the X and Y co-ordinates of the mouse pointer directly.

Unfortunately the /dev/mouse driver presented by the zts driver sends absolute position events which are scaled according to landscape orientation. This means that the zts screen is no longer aligned with the mouse pointer when in portrait mode.

To observe this issue switch the screen to portrait (comment out the Option "rotate" "CW" from the wsfb section) and switch the mouse to portrait mode too (uncomment the Option "Rotate" "CCW" from the ws section). What you will observe is that the mouse pointer will drift away from the stylus as the stylus is placed further away from the origin. This means that the scaling is off when in portrait mode and is explained by the fact that the wsdv_drv driver uses the scaled position of the X co-ordinate against the Y axis and vica versa. This is a non issue for devices that don't require scaling/calibration but is a big issue for devices that do.

This explanation confirms why the screen works in standard landscape mode (no Rotate on ws and CW rotate on wsfb) and also in upside down mode (UD rotate on ws driver and CCW rotate on wsfb) since the scaling factor for an inverted screen is the same as for the standard orientation.

The issue cannot be fixed by coding scaling rotation into the ws driver within X since this driver is also handling the USB mouse and such an attempt would cause problems with the USB mouse. The only possible solution here would be for the ws driver to positively identify the touch screen via an IOCTL (WSMOUSE_TYPE_TPANEL is feasible) and to then recalculate the scaling factor. This is messy since the scaling factor is already applied to the co-ordinates by the zts driver and would require the ws driver to work back and re-apply the scaling factor to the rotated co-ordinates that it sends.

My proposal for solution is as follows (I may fix this but I want to get feedback before starting)..

i. Implement an IOCTL on zts to switch scaling behaviour based upon a provided screen orientation, this may suit the purposes of developers wishing to use touch screen orientation independently of X.

ii. Modify the ws driver to check the IOCTL on each mouse driver to see if this extension exists, if it does exist then it will use this extension to program the IOCTL to modify its scaling behaviour for landscape or portrait so that co-ordinates returned are scaled correctly for visual transformation by drivers such as wsfb.

Common objections may be..

a. This is adding a non standard IOCTL to a common driver type.
b. It's an X issue so changes shouldn't effect the kernel. - could benefit non X software though.

Please let me know what you think about the suitability of this as a solution or any other possible suitable solutions.

- Andy

Reply | Threaded
Open this post in threaded view
|

Re: Request for comments on zts rotational scaling issue

Matthieu Herrb
Andrew Smith wrote:

> There is an issue with running the Zaurus touch screen driver in portrait mode in X.
>
> The issue is as follows.
>
> The zts driver provides /dev/wsmouse as standard and this is accessed through the ws_drv.so mouse driver.
>
> A USB Mouse will connect on the Zaurus as /dev/wsmouse1 which will also be accessed through the ws_drv.so driver.
>
> The zts driver requires a certain amount of calibration and internally handles scalinig factors for X and Y co-ordinates. In the standard mode of operation the ws driver through zts handles the mouse in Landscape mode.
>
> When the wsfb_drv.so screen driver is placed into portrait mode it starts to translate mouse co-ordinates to a 90 degree rotation (or 270 degree if placed in inverse portrait mode). To accomplish this it starts to manipulate the X and Y co-ordinates of the mouse pointer directly.
>
> Unfortunately the /dev/mouse driver presented by the zts driver sends absolute position events which are scaled according to landscape orientation. This means that the zts screen is no longer aligned with the mouse pointer when in portrait mode.
>
> To observe this issue switch the screen to portrait (comment out the Option "rotate" "CW" from the wsfb section) and switch the mouse to portrait mode too (uncomment the Option "Rotate" "CCW" from the ws section). What you will observe is that the mouse pointer will drift away from the stylus as the stylus is placed further away from the origin. This means that the scaling is off when in portrait mode and is explained by the fact that the wsdv_drv driver uses the scaled position of the X co-ordinate against the Y axis and vica versa. This is a non issue for devices that don't require scaling/calibration but is a big issue for devices that do.
>
> This explanation confirms why the screen works in standard landscape mode (no Rotate on ws and CW rotate on wsfb) and also in upside down mode (UD rotate on ws driver and CCW rotate on wsfb) since the scaling factor for an inverted screen is the same as for the standard orientation.
>
> The issue cannot be fixed by coding scaling rotation into the ws driver within X since this driver is also handling the USB mouse and such an attempt would cause problems with the USB mouse. The only possible solution here would be for the ws driver to positively identify the touch screen via an IOCTL (WSMOUSE_TYPE_TPANEL is feasible) and to then recalculate the scaling factor. This is messy since the scaling factor is already applied to the co-ordinates by the zts driver and would require the ws driver to work back and re-apply the scaling factor to the rotated co-ordinates that it sends.
>
> My proposal for solution is as follows (I may fix this but I want to get feedback before starting)..
>
> i. Implement an IOCTL on zts to switch scaling behaviour based upon a provided screen orientation, this may suit the purposes of developers wishing to use touch screen orientation independently of X.
>
> ii. Modify the ws driver to check the IOCTL on each mouse driver to see if this extension exists, if it does exist then it will use this extension to program the IOCTL to modify its scaling behaviour for landscape or portrait so that co-ordinates returned are scaled correctly for visual transformation by drivers such as wsfb.
>
> Common objections may be..
>
> a. This is adding a non standard IOCTL to a common driver type.
> b. It's an X issue so changes shouldn't effect the kernel. - could benefit non X software though.
>
> Please let me know what you think about the suitability of this as a solution or any other possible suitable solutions.
>
> - Andy

The X.Org people are currently desining a new extension to make it
possible to pass arbitrarly key/value configuration dynamically to
existing drivers (especially input drivers) to solve on-line
calibration, rotation and other similar issues. Once it's done, the ws
input driver will be able to take advantage of it.

And may be in the mean time we'll have a working randr support for wsfb
too.

--
Matthieu Herrb

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]