I think its best to disable the internal translation of this keyboard and let the kernel manage it. It can be done by implementing a fixup table that first translates all the media controls to their respective F keys, and other similar internal translations, so that the keyboard can mimic the original Apple version. Like the all the 3 fn modes should also work. Also looking at the keyboard pic on https://www.amazon.in/OMOTON-Ultra-Slim-Bluetooth-Keyboard-Compatible/dp/B07S7VPQG6?th=1, the translation table for magic keyboard aluminium seems quite different from what this keyboard keys show. > On 16 Feb 2025, at 11:36 AM, Aditya Garg <gargaditya08@xxxxxxxx> wrote: > > 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 > >
