diff mbox series

[resend] HID: apple: fix up the F6 key on the Omoton KB066 keyboard

Message ID 20250117061254.196702-1-alexhenrie24@gmail.com (mailing list archive)
State New
Delegated to: Jiri Kosina
Headers show
Series [resend] HID: apple: fix up the F6 key on the Omoton KB066 keyboard | expand

Commit Message

Alex Henrie Jan. 17, 2025, 6:12 a.m. UTC
The Omoton KB066 is an Apple A1255 keyboard clone (HID product code
05ac:022c). On both keyboards, the F6 key becomes Num Lock when the Fn
key is held. But unlike its Apple exemplar, when the Omoton's F6 key is
pressed without Fn, it sends the usage code 0xC0301 from the reserved
section of the consumer page instead of the standard F6 usage code
0x7003F from the keyboard page. The nonstandard code is translated to
KEY_UNKNOWN and becomes useless on Linux. The Omoton KB066 is a pretty
popular keyboard, judging from its 29,058 reviews on Amazon at time of
writing, so let's account for its quirk to make it more usable.

By the way, it would be nice if we could automatically set fnmode to 0
for Omoton keyboards because they handle the Fn key internally and the
kernel's Fn key handling creates undesirable side effects such as making
F1 and F2 always Brightness Up and Brightness Down in fnmode=1 (the
default) or always F1 and F2 in fnmode=2. Unfortunately I don't think
there's a way to identify Bluetooth keyboards more specifically than the
HID product code which is obviously inaccurate. Users of Omoton
keyboards will just have to set fnmode to 0 manually to get full Fn key
functionality.

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
---
 drivers/hid/hid-apple.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Jiri Kosina Feb. 3, 2025, 9:57 p.m. UTC | #1
On Thu, 16 Jan 2025, Alex Henrie wrote:

> The Omoton KB066 is an Apple A1255 keyboard clone (HID product code
> 05ac:022c). On both keyboards, the F6 key becomes Num Lock when the Fn
> key is held. But unlike its Apple exemplar, when the Omoton's F6 key is
> pressed without Fn, it sends the usage code 0xC0301 from the reserved
> section of the consumer page instead of the standard F6 usage code
> 0x7003F from the keyboard page. The nonstandard code is translated to
> KEY_UNKNOWN and becomes useless on Linux. The Omoton KB066 is a pretty
> popular keyboard, judging from its 29,058 reviews on Amazon at time of
> writing, so let's account for its quirk to make it more usable.
> 
> By the way, it would be nice if we could automatically set fnmode to 0
> for Omoton keyboards because they handle the Fn key internally and the
> kernel's Fn key handling creates undesirable side effects such as making
> F1 and F2 always Brightness Up and Brightness Down in fnmode=1 (the
> default) or always F1 and F2 in fnmode=2. Unfortunately I don't think
> there's a way to identify Bluetooth keyboards more specifically than the
> HID product code which is obviously inaccurate. Users of Omoton
> keyboards will just have to set fnmode to 0 manually to get full Fn key
> functionality.
> 
> Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
> ---
>  drivers/hid/hid-apple.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> index 7e1ae2a2bcc2..9767d17941d0 100644
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
> @@ -545,6 +545,9 @@ static int hidinput_apple_event(struct hid_device *hid, struct input_dev *input,
>  		}
>  	}
>  
> +	if (usage->hid == 0xc0301) /* Omoton KB066 quirk */
> +		code = KEY_F6;
> +

Sorry, it's not clear to me from the changelog why it's not possible to 
make this quirk apply only in case we're known to have 0x5ac/0x022c 
device. Is this VID/PID shared with other, differently-behaving devices?

Thanks,
Alex Henrie Feb. 5, 2025, 3:02 a.m. UTC | #2
On Mon, Feb 3, 2025 at 2:57 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Thu, 16 Jan 2025, Alex Henrie wrote:

> > diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> > index 7e1ae2a2bcc2..9767d17941d0 100644
> > --- a/drivers/hid/hid-apple.c
> > +++ b/drivers/hid/hid-apple.c
> > @@ -545,6 +545,9 @@ static int hidinput_apple_event(struct hid_device *hid, struct input_dev *input,
> >               }
> >       }
> >
> > +     if (usage->hid == 0xc0301) /* Omoton KB066 quirk */
> > +             code = KEY_F6;
> > +
>
> Sorry, it's not clear to me from the changelog why it's not possible to
> make this quirk apply only in case we're known to have 0x5ac/0x022c
> device. Is this VID/PID shared with other, differently-behaving devices?

The real Apple A1255 and the Omoton KB066 are both 05ac:022c. The
hid-apple driver is only used for devices that have VID 05ac, so
there's no need to check the VID again. We could restrict the quirk to
PID 022c only, but if the keyboard emits the reserved code 0xC0301,
it's surely an Omoton KB066 because no other keyboard uses that code.
What would be the advantage to adding a PID check?

-Alex
diff mbox series

Patch

diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 7e1ae2a2bcc2..9767d17941d0 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -545,6 +545,9 @@  static int hidinput_apple_event(struct hid_device *hid, struct input_dev *input,
 		}
 	}
 
+	if (usage->hid == 0xc0301) /* Omoton KB066 quirk */
+		code = KEY_F6;
+
 	if (usage->code != code) {
 		input_event_with_scancode(input, usage->type, code, usage->hid, value);