Hi Benjamin,
Can you please provide guidance on how to workaround this problem? Is it
possible to support the 4.14 kernel behaviour again, so that existing
clients are not impacted?
Thanks
Neeraj
On 11/14/2019 10:01 AM, Neeraj Upadhyay wrote:
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
