Re: Query regarding hid-multitouch.c driver in 4.14/4.19

From: Neeraj Upadhyay
Date: Wed Nov 13 2019 - 23:32:23 EST

Hi Benjamin,

Sorry for the delay, was waiting for the required information from our team.

On 11/13/2019 3:00 PM, Benjamin Tissoires wrote:
Hi Neeraj,

On Wed, Nov 13, 2019 at 4:11 AM Neeraj Upadhyay <neeraju@xxxxxxxxxxxxxx> wrote:
Hi,

I have one query regarding hid-multitouch.c driver and need your guidance on
how hid-multitouchc can restore/support the original behaviour, where, for
devices, for which application is not
HID_DG_TOUCHSCREEN/HID_DG_TOUCHPAD, and has
HID_DG_CONTACTID usage in its report, can still use generic input mappings.

We are using kernel versions 4.14 , 4.19 respectively in 2 different
projects:

4.14:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/hid/hid-multitouch.c?h=v4.14.153
4.19:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/hid/hid-multitouch.c?h=v4.19.83

I checked the application for our hid device, it's HID_DG_PEN, device
also has a HID_DG_CONTACTID usage defined in

its report.

In 4.19, is_mt_collection is set to 'true'. All multitouch code paths or
input mapping is configured

mt_allocate_report_data()
...
for (n = 0; n < field->report_count; n++) {
if (field->usage[n].hid == HID_DG_CONTACTID)
rdata->is_mt_collection = true; //
is_mt_collection is set to 'true'
}
}

mt_input_mapping()
...
if (rdata->is_mt_collection)
return mt_touch_input_mapping(...) //
mt_touch_input_mapping() is called

mt_event()
if (rdata && rdata->is_mt_collection)
return mt_touch_event(); // mt_touch_event() is called

However, in 4.14, the behaviour was different, mt input mapping was done
only
for HID_DG_TOUCHSCREEN/HID_DG_TOUCHPAD , and because our hid device is
HID_DG_PEN, generic mappings were applied for it; with these settings,
device
responds to events.

static int mt_input_mapping()
if (field->application == HID_DG_TOUCHSCREEN ||
field->application == HID_DG_TOUCHPAD)
return mt_touch_input_mapping(); // This is not called.


mt_touch_input_mapping()
case HID_DG_CONTACTID:
mt_store_field(usage, td, hi);
td->touches_by_report++;
td->mt_report_id = field->report->id; //
mt_report_id is not set.
return 1;


Looks like this behaviour changed, with below commits:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/hid/hid-multitouch.c?h=v4.19.83&id=8dfe14b3b47ff832cb638731f9fc696a3a84f804
8dfe14b3b47f HID: multitouch: ditch mt_report_id
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/hid/hid-multitouch.c?h=v4.19.83&id=ba6b055e0f3b4ff4942e4ab273260affcfad9bff
ba6b055e0f3b HID: input: enable Totem on the Dell Canvas 27

Can you please suggest on how we can support/preserve the original
behaviour?
Hmm, I would initially say that a firmware that exports Contact ID for
a Pen is definitely wrong. The Contact ID usage has been introduced in
https://www.usb.org/sites/default/files/hutrr34.pdf and is
specifically for multi-touch, not multi pen.

Anyway, couple of questions:
- does the device supports multi-pen?

Actually the device is a selfie stick device: https://item.jd.com/33082497741.html

It does not support multi-pen.

- can you share the report descriptor and a few events when triggering
this particular report (ideally with hid-recorder from
https://gitlab.freedesktop.org/libevdev/hid-tools/

Report descriptor is below:

05 0d 09 02 a1 01 85 01 09 22 a1 02 09 42 15 00 25 01 75 01 95 01 81 02 09 32 81 02 95 06 81 03 75 08 09 51 95 01 81 02 05 01 26 ff 0f 75 10 55 0e 65 33 09 30 35 00 46 b5 04 81 02 46 8a 03 09 31 81 02 c0 05 0d 09 54 95 01 75 08 81 02 85 08 09 55 25 05 b1 02 c0 05 0c 09 01 a1 01 85 02 09 e9 09 ea 0a ae 01 09 e2 09 30 15 01 25 0c 75 10 95 01 81 00 c0

Events were collected using getevent call in adb shell in android:

On 4.19

# getevent -l

add device 7: /dev/input/event6
 name: "BLE-M1 UNKNOWN"

/dev/input/event6: EV_ABSÂÂÂÂÂÂ ABS_MT_TRACKING_IDÂÂ 00000000
/dev/input/event6: EV_ABSÂÂÂÂÂÂ ABS_MT_POSITION_XÂÂÂ 00000800
/dev/input/event6: EV_ABSÂÂÂÂÂÂ ABS_MT_POSITION_YÂÂÂ 00000d60
/dev/input/event6: EV_KEYÂÂÂÂÂÂ BTN_TOUCHÂÂÂÂÂÂÂÂÂÂÂ DOWN
/dev/input/event6: EV_SYNÂÂÂÂÂÂ SYN_REPORTÂÂÂÂÂÂÂÂÂÂ 00000000
/dev/input/event6: EV_ABSÂÂÂÂÂÂ ABS_MT_TRACKING_IDÂÂ ffffffff
/dev/input/event6: EV_KEYÂÂÂÂÂÂ BTN_TOUCHÂÂÂÂÂÂÂÂÂÂÂ UP
/dev/input/event6: EV_SYNÂÂÂÂÂÂ SYN_REPORTÂÂÂÂÂÂÂÂÂÂ 00000000
/dev/input/event6: EV_ABSÂÂÂÂÂÂ ABS_MT_TRACKING_IDÂÂ 00000001
/dev/input/event6: EV_KEYÂÂÂÂÂÂ BTN_TOUCHÂÂÂÂÂÂÂÂÂÂÂ DOWN
/dev/input/event6: EV_SYNÂÂÂÂÂÂ SYN_REPORTÂÂÂÂÂÂÂÂÂÂ 00000000
/dev/input/event6: EV_ABSÂÂÂÂÂÂ ABS_MT_TRACKING_IDÂÂ ffffffff
/dev/input/event6: EV_KEYÂÂÂÂÂÂ BTN_TOUCHÂÂÂÂÂÂÂÂÂÂÂ UP
/dev/input/event6: EV_SYNÂÂÂÂÂÂ SYN_REPORTÂÂÂÂÂÂÂÂÂÂ 00000000

On 4.14

add device 2: /dev/input/event5
 name: "BLE-M1 UNKNOWN"

/dev/input/event5: EV_MSCÂÂÂÂÂÂ MSC_SCANÂÂÂÂÂÂÂÂÂÂÂÂ 000d0042
/dev/input/event5: EV_KEYÂÂÂÂÂÂ BTN_TOUCHÂÂÂÂÂÂÂÂÂÂÂ DOWN
/dev/input/event5: EV_KEYÂÂÂÂÂÂ BTN_DIGIÂÂÂÂÂÂÂÂÂÂÂÂ DOWN
/dev/input/event5: EV_ABSÂÂÂÂÂÂ ABS_MISCÂÂÂÂÂÂÂÂÂÂÂÂ 00000001
/dev/input/event5: EV_ABSÂÂÂÂÂÂ ABS_XÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 00000800
/dev/input/event5: EV_ABSÂÂÂÂÂÂ ABS_YÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 00000d60
/dev/input/event5: EV_ABSÂÂÂÂÂÂ 0029ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 00000001
/dev/input/event5: EV_SYNÂÂÂÂÂÂ SYN_REPORTÂÂÂÂÂÂÂÂÂÂ 00000000

/dev/input/event5: EV_MSCÂÂÂÂÂÂ MSC_SCANÂÂÂÂÂÂÂÂÂÂÂÂ 000d0042
/dev/input/event5: EV_KEYÂÂÂÂÂÂ BTN_TOUCHÂÂÂÂÂÂÂÂÂÂÂ UP
/dev/input/event5: EV_KEYÂÂÂÂÂÂ BTN_DIGIÂÂÂÂÂÂÂÂÂÂÂÂ UP
/dev/input/event5: EV_ABSÂÂÂÂÂÂ 0029ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 00000000
/dev/input/event5: EV_SYNÂÂÂÂÂÂ SYN_REPORTÂÂÂÂÂÂÂÂÂÂ 00000000

/dev/input/event5: EV_MSCÂÂÂÂÂÂ MSC_SCANÂÂÂÂÂÂÂÂÂÂÂÂ 000d0042
/dev/input/event5: EV_KEYÂÂÂÂÂÂ BTN_TOUCHÂÂÂÂÂÂÂÂÂÂÂ DOWN
/dev/input/event5: EV_KEYÂÂÂÂÂÂ BTN_DIGIÂÂÂÂÂÂÂÂÂÂÂÂ DOWN
/dev/input/event5: EV_ABSÂÂÂÂÂÂ 0029ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 00000001
/dev/input/event5: EV_SYNÂÂÂÂÂÂ SYN_REPORTÂÂÂÂÂÂÂÂÂÂ 00000000

/dev/input/event5: EV_MSCÂÂÂÂÂÂ MSC_SCANÂÂÂÂÂÂÂÂÂÂÂÂ 000d0042
/dev/input/event5: EV_KEYÂÂÂÂÂÂ BTN_TOUCHÂÂÂÂÂÂÂÂÂÂÂ UP
/dev/input/event5: EV_KEYÂÂÂÂÂÂ BTN_DIGIÂÂÂÂÂÂÂÂÂÂÂÂ UP
/dev/input/event5: EV_ABSÂÂÂÂÂÂ 0029ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 00000000
/dev/input/event5: EV_SYNÂÂÂÂÂÂ SYN_REPORTÂÂÂÂÂÂÂÂÂÂ 00000000


As I have little understanding of the framework, use cases and of the flow, I am sorry, if the information provided above is

incomplete (w.r.t. what you were expecting).


Thanks

Neeraj

Cheers,
Benjamin


Thanks
Neeraj

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation