All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hutterer <peter.hutterer@who-t.net>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: "open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
	Jiri Kosina <jikos@kernel.org>, Wen He <wen.he_1@nxp.com>
Subject: Re: [PATCH RESEND] HID: input: do not run GET_REPORT unless there's a Resolution Multiplier
Date: Thu, 28 May 2020 13:03:51 +1000	[thread overview]
Message-ID: <20200528030351.GA564029@koala> (raw)
In-Reply-To: <CAO-hwJ+FbXu2X7j3tCuKDtVp7UAmSz6m8nipZX4Je1CQf2TdQQ@mail.gmail.com>

On Fri, May 15, 2020 at 09:48:18AM +0200, Benjamin Tissoires wrote:
> Hi Peter,
> 
> On Fri, May 15, 2020 at 12:49 AM Peter Hutterer
> <peter.hutterer@who-t.net> wrote:
> >
> > hid-multitouch currently runs GET_REPORT for Contact Max and again to
> > retrieve the Win8 blob. If both are within the same report, the
> > Resolution Multiplier code calls GET_FEATURE again and this time,
> > possibly due to timing, it causes the ILITEK-TP device interpret the
> > GET_FEATURE as an instruction to change the mode and effectively stop
> > the device from functioning as expected.
> >
> > Notably: the device doesn't even have a Resolution Multiplier so it
> > shouldn't be affected by any of this at all.
> >
> > Fix this by making sure we only execute GET_REPORT if there is
> > a Resolution Multiplier in the respective report.
> >
> > Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> > Tested-by: Wen He <wen.he_1@nxp.com>
> > ---
> > Same patch as before, but this time with diff.noprefix set to false again.
> > Too bad that setting messes up format-patch :( Apologies for the broken
> > one.
> 
> Thanks for the quick respin. I was about to apply it, and then I
> realized that something was off (see inlined)
> 
> >
> >  drivers/hid/hid-input.c | 22 ++++++++++++----------
> >  1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> > index dea9cc65bf80..a54824d451bf 100644
> > --- a/drivers/hid/hid-input.c
> > +++ b/drivers/hid/hid-input.c
> > @@ -1560,21 +1560,12 @@ static bool __hidinput_change_resolution_multipliers(struct hid_device *hid,
> >  {
> >         struct hid_usage *usage;
> >         bool update_needed = false;
> > +       bool get_report_completed = false;
> >         int i, j;
> >
> >         if (report->maxfield == 0)
> >                 return false;
> >
> > -       /*
> > -        * If we have more than one feature within this report we
> > -        * need to fill in the bits from the others before we can
> > -        * overwrite the ones for the Resolution Multiplier.
> > -        */
> > -       if (report->maxfield > 1) {
> > -               hid_hw_request(hid, report, HID_REQ_GET_REPORT);
> > -               hid_hw_wait(hid);
> > -       }
> > -
> >         for (i = 0; i < report->maxfield; i++) {
> >                 __s32 value = use_logical_max ?
> >                               report->field[i]->logical_maximum :
> > @@ -1593,6 +1584,17 @@ static bool __hidinput_change_resolution_multipliers(struct hid_device *hid,
> >                         if (usage->hid != HID_GD_RESOLUTION_MULTIPLIER)
> >                                 continue;
> >
> > +                       /*
> > +                        * If we have more than one feature within this report we
> > +                        * need to fill in the bits from the others before we can
> > +                        * overwrite the ones for the Resolution Multiplier.
> > +                        */
> > +                       if (!get_report_completed && report->maxfield > 1) {
> > +                               hid_hw_request(hid, report, HID_REQ_GET_REPORT);
> 
> I think here we said that the reading of this particular feature was
> mandatory by Microsoft, but what if a device doesn't like it.
> I wonder if we should not guard this against HID_QUIRK_NO_INIT_REPORTS
> too, in the event we need to quirk a particular device.

just to clarify: "I wonder if" means "please add this" here? :)

tbh I don't see how a device could function if one cannot read the report
with the RM - Windows reads and sets it unconditionally so that device would
break under Windows. Which, presumably, is motivation enough for a vendor to
fix it.

I'm not even sure there are devices where this is ever triggered now, having
two unrelated features in the same report seems a bit of a niche case.
We can easily add the check but whether it'll ever be needed is doubtful.

Cheers,
   Peter


  reply	other threads:[~2020-05-28  3:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14 11:14 [PATCH] HID: input: do not run GET_REPORT unless there's a Resolution Multiplier Peter Hutterer
2020-05-14 12:31 ` Benjamin Tissoires
2020-05-14 22:49   ` [PATCH RESEND] " Peter Hutterer
2020-05-15  7:48     ` Benjamin Tissoires
2020-05-28  3:03       ` Peter Hutterer [this message]
2020-06-09  6:03 ` [PATCH v2] " Peter Hutterer
2020-06-16 15:25   ` Jiri Kosina

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=20200528030351.GA564029@koala \
    --to=peter.hutterer@who-t.net \
    --cc=benjamin.tissoires@redhat.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=wen.he_1@nxp.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.