From: "José Expósito" <jose.exposito89@gmail.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>,
Peter Hutterer <peter.hutterer@who-t.net>,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/1] Do not map BTN_RIGHT/MIDDLE on buttonpads
Date: Wed, 24 Nov 2021 20:53:15 +0100 [thread overview]
Message-ID: <20211124195315.GA9441@elementary> (raw)
In-Reply-To: <CAO-hwJLB8h6fQRF8UjN3rER_6xS2Shi3ffEr92PhkVCijtYRpQ@mail.gmail.com>
Hi Benjamin,
Thank you very much for your quick answer.
On Wed, Nov 24, 2021 at 10:39:02AM +0100, Benjamin Tissoires wrote:
> As long as udev intrinsic is happy with it (and it correctly tags the
> touchpad as ID_INPUT_something), I'm fine with it.
Yes, the device is still tagged correctly. For example, this is the original
output for "libinput record" (libinput issue 674):
Supported Events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 272 (BTN_LEFT)
Event code 273 (BTN_RIGHT)
Event code 325 (BTN_TOOL_FINGER)
[...]
udev:
properties:
- ID_INPUT=1
- ID_INPUT_HEIGHT_MM=61
- ID_INPUT_TOUCHPAD=1
- ID_INPUT_WIDTH_MM=93
And the same output after applying the patch:
Supported Events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 272 (BTN_LEFT)
Event code 325 (BTN_TOOL_FINGER)
[...]
udev:
properties:
- ID_INPUT=1
- ID_INPUT_HEIGHT_MM=61
- ID_INPUT_TOUCHPAD=1
- ID_INPUT_WIDTH_MM=93
Notice that BTN_RIGHT is not present but the udev tags are the same.
I don't have access to that specific touchpad, but I own a Magic
Trackpad 1 and 2 -whose driver clears the BTN_RIGHT bit- and they
are properly tagged as well.
> I think it depends if you plan on fixing just hid-multitouch or the others.
> If you have more than one driver, then yes, adding a new symbol in
> hid-input.c makes sense. If not, then you are just exposing a new
> function we won't know if there are users and we won't be able to
> change without care.
I'd like to fix the issue on every driver. It is not a big amount of
duplicated code, just a couple of lines on drivers that don't already
clear the BTN_RIGHT/MIDDLE bit, but I agree with you, moving into a
common function is cleaner.
Also, the "input_set_property" function would allow us to add more
conditions associated with other properties in case we wanted to.
Thanks again for your input, I'll send the patchset for review as soon as
possible.
Jose
next prev parent reply other threads:[~2021-11-24 19:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 19:12 [PATCH 0/1] Do not map BTN_RIGHT/MIDDLE on buttonpads José Expósito
2021-11-23 19:12 ` [PATCH 1/1] HID: multitouch: only map BTN_LEFT " José Expósito
2021-11-24 8:43 ` kernel test robot
2021-11-24 9:39 ` [PATCH 0/1] Do not map BTN_RIGHT/MIDDLE " Benjamin Tissoires
2021-11-24 19:53 ` José Expósito [this message]
2021-12-01 5:56 ` Peter Hutterer
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=20211124195315.GA9441@elementary \
--to=jose.exposito89@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.hutterer@who-t.net \
/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