Revision as of 23:05, 9 June 2011

Status

The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:

HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev uses libmtdev in order to easily support both of the protocol A and B exposed by the kernel.

Touch Latency

When dealing with touch based interaction concepts, it is critical to minimize time difference between when the user attempts to interact with the UI and when the user receives feedback that something is happening. The variables at play which contribute heavily to this latency include:

1. Firmware touch detection (it takes time for the hardware to filter out noise to determine that an actual finger touched the screen vs. an errant capacitance change)
2. Kernel driver processing time
3. Time between when the kernel is done and when the X input driver pulls the event out
4. X input driver processing
5. Time between when the input driver is done and when an Qt application receives the event
6. Qt processing time
7. Application code processing time which results in the UI changing
8. The time between when the UI changes and when the next vblank occurs such that the user can actually *see* the result (which may require additional time to post a damage event to the window manager, the compositing of the new UI, and then a vblank)

By instrumenting the xorg-x11-driver-mtev we can determine the amount of time spent between 2 through 5. By instrumenting Qt we can determine the time spent between 5 and 7. Accurately measuring the time between 7 and 8 is difficult. For the purpose of measuring the part that we can control in the touch stack, measuring 2 through 7 is sufficient.

Using Touch with MeeGo

MeeGo 1.2 provides a GestureArea element derived from the qml-gesturearea project.

Gesture support in Qt

As gesture support is added to the official versions QML, MeeGo will work to maintain compatibility with those features in a way which allows applications written with the MeeGo Components' GestureArea to still work.

For the current status of Gesture support in Qt, you can see the following bugreports:

• PinchArea
• PanArea
• TouchArea. The GIT tree for TouchArea is here.
• Additional information.

multiple input device support

Qt on MeeGo is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See BMC#17865 if you have something to add to this topic.

core pointer

If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc. This is typically the behavior you want.

However, if you don't want the touch device to control the pointer, you can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller    id=13   [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=16   [slave  pointer  (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

NOTE: If you don't have xinput, you can install it on MeeGo by running:

zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:

xinput reattach 13 2

'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:

Option "SendCoreEvents" "false"

to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:

Section "InputClass"
        Identifier "Cando Multi Touch Panel"
        MatchVendor "Cando"
        MatchDevicePath "/dev/input/event*"
        Driver "mtev"
        Option "SendCoreEvents" "false"
EndSection

meego packages you may need

To perform the above steps on this wiki, you may need to install the xinput utility:

zypper install xorg-x11-utils-xinput

Troubleshooting

touch doesn't work on my system

If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See BMC#12777 for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);