> On 24 Feb 2025, at 11:18 AM, Alex Henrie <alexhenrie24@xxxxxxxxx> wrote:
>
> On Sun, Feb 23, 2025 at 10:40 PM Aditya Garg <gargaditya08@xxxxxxxx> wrote:
>
>>> On 24 Feb 2025, at 11:07 AM, Alex Henrie <alexhenrie24@xxxxxxxxx> wrote:
>
>>> +static bool apple_is_omoton_kb066(struct hid_device *hdev)
>>> +{
>>> + return hdev->product == USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI &&
>>> + strcmp(hdev->name, "Bluetooth Keyboard") == 0;
>>> +}
>>> +
>>
>> Should be make a table here so that similar keyboards who want fn to be disabled can be put?
>
> Since there is only one known keyboard with this problem right now, a
> table seems superfluous, but I would be happy to add one if the
> maintainers want it.
>
>>> - if ((asc->quirks & APPLE_HAS_FN) && !asc->fn_found) {
>>> + if (((asc->quirks & APPLE_HAS_FN) && !asc->fn_found) || apple_is_omoton_kb066(hdev)) {
>>> hid_info(hdev, "Fn key not found (Apple Wireless Keyboard clone?), disabling Fn key handling\n");
>>
>> Probably change the message here to Fn key not found or has internal handling
>
> In my opinion, we don't need to change the message. If we found an
> Omoton keyboard, that means that the Fn key that we found in the HID
> descriptor isn't real, so it's fair to say that we did not find an Fn
> key.
>
Fair enough, lets see what Jiri decides.
