Linux/android Multi-Touch Protocol "Go"

This article is reproduced from:

Link Click to open link

On the Linux multi-Touch protocol, you can refer to the documentation in kernel: Https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt, which is based on practical examples to understand the multi-touch protocol.

There are two kinds of multi-touch protocols, a protocol and B protocol.

First of all, a protocol, the agreement said the paper format is this, take two points as an example:

abs_mt_position_x x[0] abs_mt_position_y y[0] syn_mt_report abs_mt_position_x x[1] Abs_mt_posi Tion_y Y[1] Syn_mt_report syn_report

If the first contact is left (lifted), this means that there is still one contact, which needs to be escalated to the point.

abs_mt_position_x x[1] abs_mt_position_y y[1] Syn_mt_report syn_report

If two contacts are left, then only one synchronization event can be reported.

Syn_mt_report Syn_report

The code example is as follows:

[CPP]View PlainCopy

1. for  (i = 0; i <  count; i++)  {  
2.         input _report_abs (input_dev, abs_mt_position_x, finger[i].x);   
3.          input_report_abs (input_dev, abs_mt_position_y, finger[i].x);   
4.         input_mt_sync (Input_dev);  
5. }&NBSP;&NBSP;
6.   
7. if  (! Count)   
8.         input_mt_sync (Input_dev);   
9. &NBSP;&NBSP;
10. Input_sync (Input_dev);   

Where the Count value indicates the number of contacts, if 2, then the value is 2, and if all the contacts are left, then the count value is 0.

The above can be said to be the simplest, but also the most basic of a protocol report point. In addition to the reporting point, we also look at some of the things that need to be setting when the input device is registered.

[CPP]View PlainCopy

1. Input_set_abs_params (Input_dev, abs_mt_position_x, 0, max_x, 0, 0);
2. Input_set_abs_params (Input_dev, abs_mt_position_y, 0, max_y, 0, 0);
4. __set_bit (Ev_syn, input_dev->evbit);
5. __set_bit (Ev_abs, input_dev->evbit);
7. __set_bit (Input_prop_direct, input_dev->propbit);

Perhaps you will see some code that will be more than the following two sentences:

[CPP]View PlainCopy

1. __set_bit (abs_mt_position_x, input_dev->absbit);
2. __set_bit (abs_mt_position_x, input_dev->absbit);

In fact, these two sentences (including the above __set_bit (Ev_abs, input_dev->evbit) are optional, because the corresponding settings are made in the Input_set_abs_params function.

And this sentence __set_bit (Input_prop_direct, Input_dev->propbit), but also must have, otherwise there will be a small white ring in Android, it feels like the lack of IDC files. Finally, through the getevent-p command to see the touch screen setting.

Add device 1:/dev/input/event1 name: "ft6x36" Events:abs (0003): 0035:value 0, Min 0, max 540, fuzz 0, flat 0, resolution 0 0036:value 0, Min 0, max 960, Fuzz 0, flat 0, resolution 0 input Props:input_prop_d Irect

The B protocol is a little bit more complicated. B protocol requires hardware support, and a protocol is the main difference between it? The B protocol can use an ID to identify the contact, reducing the amount of data escalated to the user's space, which can be provided by the hardware or computed from the original data (abs_mt_tracking_id). Well, we'll see how the B protocol reports the data under the >.

Abs_mt_slot 0 abs_mt_tracking_id abs_mt_position_x x[0] abs_mt_position_y y[0] Abs_mt_slot 1 abs_mt_tracking_id abs_mt_position_x x[1] abs_mt_position_y y[1] Syn_report

If the contact 45 is only moving in the x direction, how should the event be reported?

Abs_mt_slot 0 abs_mt_position_x X[0] Syn_report

You can see that a lot of data is being escalated, which is the biggest difference with a protocol.

If the contacts associated with slot 0 leave (lift), only the following actions are required. Abs_mt_tracking_id-1 Syn_report

Why not send the Abs_mt_slot 0 event here, because the SLOT has been set to 0, again send Abs_mt_slot 0 will be ignored.

If the second contact is lifted, the following sequence of events is sent.

Abs_mt_slot 1 abs_mt_tracking_id-1 Syn_report

Other event
Abs_mt_position_x and abs_mt_position_y are the minimum set of events for multi-touch protocols and are the most basic and necessary events. In addition, some of the following time sets (which require setup support) are included:
Abs_mt_touch_major
Abs_mt_touch_minor
Abs_mt_touch* is used to indicate the size of the contact area (that is, the size of the contact area of the finger and the glass), usually the contact area is an oval shape, then the major represents the long axis of the ellipse, and the minor represents the short axis of the ellipse. If the contact area is circular, then the minor can be ignored, and the major indicates the diameter of the circle.

Abs_mt_width_major
Abs_mt_width_minor
The touch above indicates the size of the contact area, while width is the size of the touch tool (e.g., finger, stylus, etc.).

Abs_mt_pressure
and pressure represents the pressure value, the pressure value can be calculated from the above 4 parameters, for example: Abs_mt_touch_major/abs_mt_width_major, you can see the greater the contact area, the greater the pressure value. Of course this pressure value can also be supplied directly from the device.

Abs_mt_distance
The distance between the contacts and the contact surface, 0 means that the contact is on the surface of the contact surface (which has been actually touched), while a positive number is indicated above the contact surface.

Abs_mt_orientation
The direction of the contact point.

Abs_mt_tool_x
Abs_mt_tool_y
Abs_mt_tool_type

About reporting Virtual key values
Usually there are 3 virtual keys under the touch screen, and these 3 keys are different from other entity keys (such as power button, Volume button), it is a set of virtual keys provided by the touch screen, we can get the coordinate value of this set of keys through the touch screen, it is possible to report the corresponding key value by this coordinate value to real
Now button function, then how to report this key value it. First you need to do some setting on the input device:

[CPP]View PlainCopy

1. __set_bit (Key_menu, input_dev->keybit);
2. __set_bit (Key_homepage, input_dev->keybit);
3. __set_bit (Key_back, input_dev->keybit);
5. __set_bit (Ev_key, input_dev->evbit);
6. __set_bit (Ev_syn, input_dev->evbit);

OK, these key values in the kernel is defined in the uapi/linux/input.h, and usually our driver only need to include linux/input.h, this file contains the uapi/linux/input.h.

OK, let's see how the key value is reported.
Press the button:

[CPP]View PlainCopy

1. Input_report_key (Input_dev, Key_value, 1);
2. Input_sync (Input_dev);

Press the button to lift up:

[CPP]View PlainCopy

1. Input_report_key (Input_dev, Key_value, 0);
2. Input_sync (Input_dev);

If the button is pressed all the time, the Repeat escalation button is pressed to the part.

Some places may see direct use of the input_event function, for example:

[CPP]View PlainCopy

1. Input_event (Input_dev, Ev_key, Key_value, 1);

You can also go to see the Input_report_key function, it is actually the input_event function to do the encapsulation, whether it is input_report_abs or input_sync, and ultimately is called the Input_event function, So the function that actually escalated the event is actually the Input_event function.

The last point in setting, in addition to __set_bit, may also see another function input_set_capability, which is implemented in drivers/input/input.c, and it eventually calls the __set_bit function , so the final effect is the same.

Linux/android Multi-Touch Protocol "Go"