On Wed, Feb 12, 2025 at 10:44 AM Aditya Garg <gargaditya08@xxxxxxxx> wrote:
> > On 12 Feb 2025, at 11:06 PM, Aditya Garg <gargaditya08@xxxxxxxx> wrote:
> >> On 17 Jan 2025, at 11:42 AM, Alex Henrie <alexhenrie24@xxxxxxxxx> 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.
> >
> > Regarding the the fnmode=0 thing, could you test this patch:
> >
> > -->8—
> > From e2b2ef3f579800f11ee293fb45838a4004ccaf23 Mon Sep 17 00:00:00 2001
> > From: Aditya Garg <gargaditya08@xxxxxxxx>
> > Date: Wed, 12 Feb 2025 22:57:58 +0530
> > Subject: [PATCH] HID: apple: Add quirk to disable fn key on some non-apple
> > keyboards
> >
> > ---
> > drivers/hid/hid-apple.c | 54 +++++++++++++++++++++++++++++------------
> > 1 file changed, 39 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> > index 49812a76b..9d4cbe636 100644
> > --- a/drivers/hid/hid-apple.c
> > +++ b/drivers/hid/hid-apple.c
> > @@ -42,6 +42,7 @@
> > #define APPLE_BACKLIGHT_CTL BIT(10)
> > #define APPLE_IS_NON_APPLE BIT(11)
> > #define APPLE_MAGIC_BACKLIGHT BIT(12)
> > +#define APPLE_DISABLE_FN BIT(13)
> >
> > #define APPLE_FLAG_FKEY 0x01
> >
> > @@ -89,6 +90,19 @@ struct apple_sc_backlight {
> > struct hid_device *hdev;
> > };
> >
> > +struct apple_backlight_config_report {
> > + u8 report_id;
> > + u8 version;
> > + u16 backlight_off, backlight_on_min, backlight_on_max;
> > +};
> > +
> > +struct apple_backlight_set_report {
> > + u8 report_id;
> > + u8 version;
> > + u16 backlight;
> > + u16 rate;
> > +};
> > +
> > struct apple_magic_backlight {
> > struct led_classdev cdev;
> > struct hid_report *brightness;
> > @@ -152,20 +166,6 @@ static const struct apple_key_translation magic_keyboard_2015_fn_keys[] = {
> > { }
> > };
> >
> > -struct apple_backlight_config_report {
> > - u8 report_id;
> > - u8 version;
> > - u16 backlight_off, backlight_on_min, backlight_on_max;
> > -};
> > -
> > -struct apple_backlight_set_report {
> > - u8 report_id;
> > - u8 version;
> > - u16 backlight;
> > - u16 rate;
> > -};
> > -
> > -
> > static const struct apple_key_translation apple2021_fn_keys[] = {
> > { KEY_BACKSPACE, KEY_DELETE },
> > { KEY_ENTER, KEY_INSERT },
> > @@ -364,6 +364,10 @@ static const struct apple_non_apple_keyboard non_apple_keyboards[] = {
> > { "WKB603" },
> > };
> >
> > +static const struct apple_non_apple_keyboard non_apple_keyboards_disable_fn[] = {
> > + { "Omoton" },
>
> You could try replacing Omoton with OMOTON as well here if it does not work. Alternatively, you could try logging hdev->name for this device and put it in this table to get the correct name.
On the Omoton KB066, hdev->name is "Bluetooth Keyboard". I think I saw
that name in Blueman and assumed that it was just a default for when a
keyboard has no name, but you're right, that string must be coming
from the keyboard itself. After changing "Omoton" to "Bluetooth
Keyboard" in non_apple_keyboards_disable_fn, your patch works!
Unfortunately, this keyboard is even more messed up than I realized.
It is indeed sending different key codes depending on whether or not
the Fn key is held. For example, F11 and F12 are Volume Down and
Volume Up by default, but ordinary F11 and F12 when Fn is held.
However, I was wrong about F1 and F2: With or without Fn, the Omoton
_never_ changes F1 to Brightness Down or F2 to Brightness Up. I
managed to pick the one bad example: All of the other special keys
(Esc, F3 through F12, and Del) are translated internally, but not F1
or F2. That also means that I was wrong about the Fn key not doing
anything in fnmode=2. When Fn is held, all of the special keys do
become ordinary keys in both fnmode=0 and fnmode=2, except for F1 and
F2 which remain ordinary F1 and F2.
When connected to macOS, the results are similar: All of the special
keys are special keys regardless of whether Fn is held, except F1 and
F2, which by default are always translated to Brightness Down and
Brightness Up like in Linux's fnmode=1. If the setting "Use F1, F2,
etc. keys as standard function keys" is enabled in the system keyboard
settings, all of the special keys change to ordinary keys when Fn is
held, except for F1 and F2 which remain F1 and F2, just like in
Linux's fnmode=0 and fnmode=2.
It seems to me that the best way to support the Omoton KB066 would be
to give it its own key translation table that has F1 and F2 and
nothing else. But on the bright side, pun humorously intended, we
wouldn't have to change the default fnmode. Just like on macOS, F1 and
F2 would always be Brightness Down and Brightness Up, unless key
translation is disabled. But unlike macOS (and the current state of
Linux), we wouldn't undo the keyboard's own Fn key handling for the
special keys that it translates internally.
Circling back to the original problem of distinguishing between the
Apple A1255 and the Omoton KB066, changing an Apple keyboard's name in
the macOS keyboard settings also changes the name that it reports to
Linux. Because "Bluetooth Keyboard" is so generic that someone might
actually give their keyboard that name intentionally, if we add
special behavior to look for that name, I think we should restrict it
to PID 022c. For example, we could add the new quirk flag to
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI in the apple_devices table and
then clear the flag if the keyboard's name is not "Bluetooth
Keyboard".
Thanks for the help!
-Alex
