Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <X//jjawwbm8FxbQU@google.com>
In-Reply-To: <X//jjawwbm8FxbQU@google.com>
From:   Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Thu, 14 Jan 2021 10:23:02 +0100
Message-ID: <CAO-hwJK5QxxX26hFiVfQr2EfnwdZSEB2paCsZBbX58iPxJvfww@mail.gmail.com>
Subject: Re: [PATCH] HID: hid-input: avoid splitting keyboard, system and
 consumer controls
To:     Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc:     Jiri Kosina <jikos@kernel.org>,
        Peter Hutterer <peter.hutterer@who-t.net>,
        "Sean O'Brien" <seobrien@chromium.org>,
        "open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Dmitry,

On Thu, Jan 14, 2021 at 7:24 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> A typical USB keyboard usually splits its keys into several reports:
>
> - one for the basic alphanumeric keys, modifier keys, F<n> keys, six pack
>   keys and keypad. This report's application is normally listed as
>   GenericDesktop.Keyboard
> - a GenericDesktop.SystemControl report for the system control keys, such
>   as power and sleep
> - Consumer.ConsumerControl report for multimedia (forward, rewind,
>   play/pause, mute, etc) and other extended keys.
> - additional output, vendor specific, and feature reports
>
> Splitting each report into a separate input device is wasteful and even
> hurts userspace as it makes it harder to determine the true capabilities
> (set of available keys) of a keyboard, so let's adjust application
> matching to merge system control and consumer control reports with
> keyboard report, if one has already been processed.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>  drivers/hid/hid-input.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index f797659cb9d9..df45d8d07dc2 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1851,6 +1851,16 @@ static struct hid_input *hidinput_match_application(struct hid_report *report)
>         list_for_each_entry(hidinput, &hid->inputs, list) {
>                 if (hidinput->application == report->application)
>                         return hidinput;
> +
> +               /*
> +                * Keep SystemControl and ConsumerControl applications together
> +                * with the main keyboard, if present.
> +                */
> +               if ((report->application == HID_GD_SYSTEM_CONTROL ||
> +                    report->application == HID_CP_CONSUMER_CONTROL) &&
> +                   hidinput->application == HID_GD_KEYBOARD) {

I am not fundamentally against the patch, but I think that if the
device exposes first a HID_CP_CONSUMER_CONTROL and then a
HID_GD_KEYBOARD we will end up with 2 different input nodes. We likely
need to "convert" HID_GD_SYSTEM_CONTROL and HID_CP_CONSUMER_CONTROL to
HID_GD_KEYBOARD when creating the hidinput.

Cheers,
Benjamin

> +                       return hidinput;
> +               }
>         }
>
>         return NULL;
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
>
> --
> Dmitry
>