linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neeraj Upadhyay <neeraju@codeaurora.org>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>,
	Henrik Rydberg <rydberg@bitmath.org>,
	"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-arm-msm@vger.kernel.org, prsood@codeaurora.org,
	gkohli@codeaurora.org
Subject: Re: Query regarding hid-multitouch.c driver in 4.14/4.19
Date: Thu, 14 Nov 2019 10:01:46 +0530	[thread overview]
Message-ID: <4eecbd2a-9d19-c6a2-a95b-656e3fce05a4@codeaurora.org> (raw)
In-Reply-To: <CAO-hwJLdz1sA4tNsLLgZKGA7Ko6dqt9VF5T2nh5uczHxU532HA@mail.gmail.com>

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@codeaurora.org> 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


  reply	other threads:[~2019-11-14  4:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-13  2:29 Query regarding hid-multitouch.c driver in 4.14/4.19 Neeraj Upadhyay
2019-11-13  9:30 ` Benjamin Tissoires
2019-11-14  4:31   ` Neeraj Upadhyay [this message]
2019-11-22  4:41     ` Neeraj Upadhyay
     [not found]     ` <0101016e916ab42c-fbc61178-9bdd-42ba-b111-722c46db5dc1-000000@us-west-2.amazonses.com>
2019-11-22  9:25       ` Benjamin Tissoires
2019-12-09  3:51         ` Neeraj Upadhyay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4eecbd2a-9d19-c6a2-a95b-656e3fce05a4@codeaurora.org \
    --to=neeraju@codeaurora.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=gkohli@codeaurora.org \
    --cc=jikos@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prsood@codeaurora.org \
    --cc=rydberg@bitmath.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).