From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Peter Hutterer <peter.hutterer@who-t.net>,
Hans Verkuil <hans.verkuil@cisco.com>,
Ping Cheng <pinglinux@gmail.com>, Kamil Debski <kamil@wypas.org>,
Douglas Anderson <dianders@chromium.org>,
linux-doc@vger.kernel.org
Subject: Re: [v3,1/4] input: add an EV_REL event for high-res vertical wheel
Date: Tue, 11 Apr 2017 07:17:28 -0300 [thread overview]
Message-ID: <20170411071728.190ec119@vento.lan> (raw)
In-Reply-To: <20170407151027.GB13764@mail.corp.redhat.com>
Em Fri, 7 Apr 2017 17:10:27 +0200
Benjamin Tissoires <benjamin.tissoires@redhat.com> escreveu:
> On Apr 07 2017 or thereabouts, Mauro Carvalho Chehab wrote:
> > Em Fri, 7 Apr 2017 14:17:51 +0200
> > Benjamin Tissoires <benjamin.tissoires@redhat.com> escreveu:
> >
> > > Hi Mauro,
> > >
> > > On Apr 07 2017 or thereabouts, Mauro Carvalho Chehab wrote:
> > > > As some devices can produce either low-res or high-res
> > > > vertical wheel EV_REL events, add a new event to allow
> > > > userspace to distinguish between them.
> > > >
> > > > Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > > > ---
> > > > Documentation/input/event-codes.rst | 16 +++++++++++++---
> > > > include/uapi/linux/input-event-codes.h | 1 +
> > > > 2 files changed, 14 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
> > > > index 92db50954169..0c8591d39bc6 100644
> > > > --- a/Documentation/input/event-codes.rst
> > > > +++ b/Documentation/input/event-codes.rst
> > > > @@ -185,10 +185,20 @@ instead of EV_REL codes.
> > > >
> > > > A few EV_REL codes have special meanings:
> > > >
> > > > -* REL_WHEEL, REL_HWHEEL:
> > > > +* REL_WHEEL:
> > > >
> > > > - - These codes are used for vertical and horizontal scroll wheels,
> > > > - respectively.
> > > > + - These codes are used for vertical scroll wheels.
> > > > +
> > > > + - REL_WHEEL is for normal wheel operational mode, e. g. low-resolution
> > > > + (line-based) scroll.
> > > > +
> > > > + - REL_HIRES_WHEEL should be used when the wheel has two resolutions and it
> > > > + is in high-resolution mode, e. g. the same angular movement that would
> > > > + produce a single REL_WHEEL will produce multiple REL_HIRES_WHEEL events.
> > > > +
> > > > +* REL_HWHEEL:
> > > > +
> > > > + - This code is used for horizontal scroll wheels.
> > > >
> > > > EV_ABS
> > > > ------
> > > > diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> > > > index 3af60ee69053..23b2d377af59 100644
> > > > --- a/include/uapi/linux/input-event-codes.h
> > > > +++ b/include/uapi/linux/input-event-codes.h
> > > > @@ -703,6 +703,7 @@
> > > > #define REL_DIAL 0x07
> > > > #define REL_WHEEL 0x08
> > > > #define REL_MISC 0x09
> > > > +#define REL_HIRES_WHEEL 0x0a
> > >
> > > There is one issue here. The HID input layer has a tendency to map
> > > usages to REL_MISC +1, +2, +3, etc... When it doesn't know how to map an
> > > usage, the core layer maps it to the next one.
> > >
> > > I am not aware of devices exposing such REL axes, but I wouldn't be
> > > surprised if the issue will not raise at some point.
> > >
> > > We already had an issue with ABS events where ABS_MISC are conflicting
> > > with ABS_MT_SLOTS. Luckily, we have a little empty space between
> > > ABS_MISC and ABS_MT_SLOT, which allows userspace to detect such issues.
> > >
> > > Could you give the define a bigger number (and maybe reserve a couple of
> > > REL_MISC-n) to make sure that we do not end up with joysticks exporting
> > > REL_HIRES_WHEEL?
> >
> > Sure. How many REL_MISC-n should be reserved?
>
> Not sure. As I mentioned, I haven' t seen such device myself, but maybe
> we should reserve the rest of the 0x0n range for those (0x0a-0x0f). This
> would force to bump REL_MAX, but I don't think this is an issue besides
> recompiling libevdev and others.
Ok, I'll do that on a separate patch.
Btw, you requested to rebase patches on the top of HID tree.
Well, if I rebase on the top of HID for_next branch, patches 1 and 2
will have (trivial) conflicts with input-next, due to the documentation
patches that got merged there.
I might rebase just patches 3 and 4, but, in this case, the HID
branch won't compile.
So, I guess either input should pull from HID or vice-versa, in order
to avoid such conflicts.
>
> >
> > > I'll try the rest of the series on the MX Master today.
> >
> > It would be great if you could test it!
>
> I found some issues, I'll report in the other patches.
Ok.
>
> Cheers,
> Benjamin
>
> >
> > Regards,
> > Mauro
Thanks,
Mauro
prev parent reply other threads:[~2017-04-11 10:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 11:31 [PATCH v3 0/4] add support for high res wheel found on some Logitech devices Mauro Carvalho Chehab
2017-04-07 11:31 ` [PATCH v3 1/4] input: add an EV_REL event for high-res vertical wheel Mauro Carvalho Chehab
2017-04-07 11:31 ` [PATCH v3 2/4] input: add a EV_SW event for ratchet switch Mauro Carvalho Chehab
2017-04-07 11:31 ` [PATCH v3 3/4] hid-logitech-hidpp: add support for high res wheel Mauro Carvalho Chehab
2017-04-07 11:31 ` [PATCH v3 4/4] hid-logitech-hidpp: add support for ratchet switch Mauro Carvalho Chehab
2017-04-07 15:33 ` Benjamin Tissoires
2017-04-07 15:31 ` [PATCH v3 3/4] hid-logitech-hidpp: add support for high res wheel Benjamin Tissoires
2017-04-07 12:17 ` [v3,1/4] input: add an EV_REL event for high-res vertical wheel Benjamin Tissoires
2017-04-07 13:32 ` Mauro Carvalho Chehab
2017-04-07 15:10 ` Benjamin Tissoires
2017-04-11 10:17 ` Mauro Carvalho Chehab [this message]
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=20170411071728.190ec119@vento.lan \
--to=mchehab@s-opensource.com \
--cc=benjamin.tissoires@redhat.com \
--cc=corbet@lwn.net \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=hans.verkuil@cisco.com \
--cc=kamil@wypas.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=peter.hutterer@who-t.net \
--cc=pinglinux@gmail.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 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).