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;
Date:   Wed, 19 May 2021 19:11:15 +0200
From:   Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>
To:     Hans de Goede <hdegoede@redhat.com>
Cc:     linux-input@vger.kernel.org, Jiri Kosina <jikos@kernel.org>,
        Benjamin Tissoires <benjamin.tissoires@redhat.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] HID: input: Add support for Programmable Buttons
Message-ID: <2acfc492-a8a9-4159-be49-dc4dc5d1614a@t-8ch.de>
References: <61dcf8c7-2dcb-4173-fbbd-9adf3412edb7@redhat.com>
 <20210519160349.609690-1-linux@weissschuh.net>
 <2dc197eb-a222-8af6-f0ab-f722e4f492ca@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2dc197eb-a222-8af6-f0ab-f722e4f492ca@redhat.com>
Jabber-ID: thomas@t-8ch.de
Precedence: bulk

Hi,

On Mi, 2021-05-19T18:13+0200, Hans de Goede wrote:
> Hi,
> 
> On 5/19/21 6:03 PM, Thomas Weißschuh wrote:
> > From: Thomas Weißschuh <thomas@t-8ch.de>
> > 
> > Map them to KEY_MACRO# event codes.
> > 
> > These buttons are defined by HID as follows:
> > "The user defines the function of these buttons to control software
> > applications or GUI objects."
> > 
> > This matches the semantics of the KEY_MACRO# input event codes that
> > Linux supports.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
> > ---
> >  drivers/hid/hid-debug.c | 11 +++++++++++
> >  drivers/hid/hid-input.c |  1 +
> >  2 files changed, 12 insertions(+)
> > 
> > diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> > index 18f5e28d475c..7d4dee58d869 100644
> > --- a/drivers/hid/hid-input.c
> > +++ b/drivers/hid/hid-input.c
> > @@ -632,6 +632,7 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> >  				else
> >  					code += BTN_TRIGGER_HAPPY - 0x10;
> >  				break;
> > +		case HID_CP_CONSUMER_CONTROL: code += KEY_MACRO1; break;
> 
> Shouldn't there be a check here to ensure that we don't map things above KEY_MACRO30 ?
> if we do that then we start hitting other codes like KEY_MACRO_RECORD_START and eventually
> BTN_TRIGGER_HAPPY and after the BTN_TRIGGER_HAPPY range we go over KEY_MAX which I think
> is not supported ?
> 
> Regards,
> 
> Hans

I thought all the other chunks of logic around this one would be affected by
this issue, too.
But actually it seems all the overflowing keys get first assigned to the
BTN_TRIGGER_HAPPY range and after that will be clipped directly by
map_key()/hid_map_usage().

I'll resend the patch.

Thanks,
Thomas