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

[Neeraj Upadhyay]

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