So if I understand correctly
If Fn mode is 0 or 2:
F1 and F2 are brightness keys
Rest are function keys
If Fn mode is 1:
F1 and F2 are function keys
Rest are media keys
Fn key does not work in any mode
In case I am wrong, can you share what exactly happens in each mode with fn on as well as off?
> On 16 Feb 2025, at 6:38 AM, Alex Henrie <alexhenrie24@xxxxxxxxx> wrote:
>
> 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
