* Re: [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
@ 2022-02-08 22:26 The Cheaterman
0 siblings, 0 replies; 6+ messages in thread
From: The Cheaterman @ 2022-02-08 22:26 UTC (permalink / raw)
To: linux-input
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
Hello,
This breaks userspace. Now XkbLayout in xorg.conf.d is ignored for my
keyboard 0d62:3740 Darfon Electronics Corp. (built into my laptop)
Attached a simple patch that fixes the issue. Obviously, a revert is
probably a better idea ; or even better yet, do the part that was kept
aside to "keep the code simple".
Given this is happening on a consumer laptop (Alienware m15 R6), I'm
probably not the only one with this issue.
Thanks for reading.
[-- Attachment #2: 0001-fix-keyboard-layout.patch --]
[-- Type: text/x-patch, Size: 596 bytes --]
--- a/hid-input.c 2022-02-08 22:56:10.850000022 +0100
+++ b/hid-input.c 2022-02-08 22:56:15.737021611 +0100
@@ -1904,16 +1904,6 @@
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) {
- return hidinput;
- }
}
return NULL;
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
@ 2021-01-14 6:24 Dmitry Torokhov
2021-01-14 9:23 ` Benjamin Tissoires
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Dmitry Torokhov @ 2021-01-14 6:24 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Peter Hutterer, seobrien, linux-input, linux-kernel
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) {
+ return hidinput;
+ }
}
return NULL;
--
2.30.0.284.gd98b1dd5eaa7-goog
--
Dmitry
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
2021-01-14 6:24 Dmitry Torokhov
@ 2021-01-14 9:23 ` Benjamin Tissoires
2021-01-14 18:43 ` Dmitry Torokhov
2021-01-15 4:44 ` Peter Hutterer
2021-02-02 10:15 ` Jiri Kosina
2 siblings, 1 reply; 6+ messages in thread
From: Benjamin Tissoires @ 2021-01-14 9:23 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Peter Hutterer, Sean O'Brien,
open list:HID CORE LAYER, lkml
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
2021-01-14 9:23 ` Benjamin Tissoires
@ 2021-01-14 18:43 ` Dmitry Torokhov
0 siblings, 0 replies; 6+ messages in thread
From: Dmitry Torokhov @ 2021-01-14 18:43 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Peter Hutterer, Sean O'Brien,
open list:HID CORE LAYER, lkml
Hi Benjamin,
On Thu, Jan 14, 2021 at 10:23:02AM +0100, Benjamin Tissoires wrote:
> 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.
While it is technically possible that consumer control or system control
comes first, before main keyboard report, in reality all keyboards that
I have seen so far have the main keyboard report first, so I opted not
to handle the uncommon case to keep the code simple.
I could add the above as a comment, and we could wait to see if there
are devices that are exceptions to the common practice, or I can go and
try to implement the conversion if you feel it is required. Please let
me know.
Note that we will still end up with 2+ input nodes if a device uses
several USB interfaces, but we can't really do much about such cases
(well, short of having a specialized driver claiming additional
interfaces while probing the first one, but that is really outside of
scope of this patch).
Thanks!
--
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
2021-01-14 6:24 Dmitry Torokhov
2021-01-14 9:23 ` Benjamin Tissoires
@ 2021-01-15 4:44 ` Peter Hutterer
2021-02-02 10:15 ` Jiri Kosina
2 siblings, 0 replies; 6+ messages in thread
From: Peter Hutterer @ 2021-01-15 4:44 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Benjamin Tissoires, seobrien, linux-input,
linux-kernel
On Wed, Jan 13, 2021 at 10:24:13PM -0800, Dmitry Torokhov 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>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
I think, let's see if there's any fallout from that :)
Cheers,
Peter
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
2021-01-14 6:24 Dmitry Torokhov
2021-01-14 9:23 ` Benjamin Tissoires
2021-01-15 4:44 ` Peter Hutterer
@ 2021-02-02 10:15 ` Jiri Kosina
2 siblings, 0 replies; 6+ messages in thread
From: Jiri Kosina @ 2021-02-02 10:15 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, Peter Hutterer, seobrien, linux-input,
linux-kernel
On Wed, 13 Jan 2021, Dmitry Torokhov 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>
> ---
Queued in for-5.12/core. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-02-08 22:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-02-08 22:26 [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls The Cheaterman
-- strict thread matches above, loose matches on Subject: below --
2021-01-14 6:24 Dmitry Torokhov
2021-01-14 9:23 ` Benjamin Tissoires
2021-01-14 18:43 ` Dmitry Torokhov
2021-01-15 4:44 ` Peter Hutterer
2021-02-02 10:15 ` Jiri Kosina
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).