linux-kernel - Re: [PATCH 12/12] Input: docs: add more details on the use of BTN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAO-hwJ+xo8yq05jPz19CoyF5x_U_O_imDXScLVhvhnm7hkdEhw@mail.gmail.com>
Date:   Mon, 14 Feb 2022 11:48:10 +0100
From:   Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:     Peter Hutterer <peter.hutterer@...-t.net>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Ahelenia Ziemiańska 
        <nabijaczleweli@...ijaczleweli.xyz>,
        Ping Cheng <pinglinux@...il.com>,
        Aaron Armstrong Skomra <skomra@...il.com>,
        Jason Gerecke <killertofu@...il.com>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 12/12] Input: docs: add more details on the use of BTN_TOOL

Hi Peter,


Looks like you commented on v1, and I made some changes in the v2 :)

On Wed, Feb 9, 2022 at 7:22 AM Peter Hutterer <peter.hutterer@...-t.net> wrote:
>
> On Wed, Jan 26, 2022 at 05:18:32PM +0100, Benjamin Tissoires wrote:
> > The HID core stack used to be very relaxed considering the BTN_TOOL_*
> > usage. With the recent commits, we should now enforce to have only one
> > tool at a time, meaning that we can now express that requirement in the
> > docs.
> >
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@...hat.com>
> > ---
> >  Documentation/input/event-codes.rst | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
> > index b24ae7d292cc..41b1fa647dab 100644
> > --- a/Documentation/input/event-codes.rst
> > +++ b/Documentation/input/event-codes.rst
> > @@ -137,7 +137,10 @@ A few EV_KEY codes have special meanings:
> >      code should be set to a value of 1. When the tool is no longer interacting
> >      with the input device, the BTN_TOOL_<name> code should be reset to 0. All
> >      trackpads, tablets, and touchscreens should use at least one BTN_TOOL_<name>
> > -    code when events are generated.
> > +    code when events are generated. Likewise all trackpads, tablets, and
> > +    touchscreens should export only one BTN_TOOL_<name> at a time. It is
>
> s/export/set to nonzero/ to avoid any ambiguity with setting the evbit on the
> device vs setting the value to nonzero.

I can carry this change in the v3.

>
> > +    however accepted to switch tool in one EV_SYN frame by setting the old
> > +    BTN_TOOL_<name> at a value of 0 and the new one at 1.
>
> I would even s/accepted/recommended/ but this LGTM to me, thanks.

In v2 I used recommended, but I turned the meaning the other way
around. In the v2 it reads:
"To not break existing userspace, it is recommended to not switch tool
in one EV_SYN frame but first emitting the old BTN_TOOL_<name> at 0,
then emit one SYN_REPORT and then set the new BTN_TOOL_<name> at 1."

So maybe I should use "accepted" in v3?

>
> Acked-by: Peter Hutterer <peter.hutterer@...-t.net>

Do I keep your acked-by in the v2/3?

Cheers,
Benjamin