From: Alex Henrie <alexhenrie24@gmail.com>
To: Aditya Garg <gargaditya08@live.com>
Cc: "open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
jkosina@suse.cz,
Benjamin Tissoires <benjamin.tissoires@redhat.com>
Subject: Re: [PATCH resend] HID: apple: fix up the F6 key on the Omoton KB066 keyboard
Date: Sun, 23 Feb 2025 19:50:56 -0700 [thread overview]
Message-ID: <CAMMLpeRg8RhncwwK7yyJsT=8Q7221euMA7=-mySN3YLFpWPQjQ@mail.gmail.com> (raw)
In-Reply-To: <A58096D0-D8FC-42F6-BCAE-8D099E81E3AA@live.com>
On Mon, Feb 17, 2025 at 3:02 AM Aditya Garg <gargaditya08@live.com> wrote:
> Can you to test the patch at the bottom of this message?
I tried it and the patch works. However, I don't think it is the right approach.
> Then see if Fn+F6 switches the media to function keys or not, and media keys work by default or not.
The main problem I have with this idea is that there is nothing to
indicate to the user that Fn+F6 switches between Fn modes. If the user
presses Fn+F6 trying to actually type F6, they will be very confused.
What all of this discussion tells me is that it's not possible to make
the Omoton KB066 work perfectly, and it's not worth our time to try.
I'm not even convinced anymore that my original patch was a good idea.
Since we know now that we can detect the Omoton reliably enough based
on its name and its PID, I suggest that we simply add "Bluetooth
Keyboard" to the non_apple_keyboards table, with a new flag to
indicate that the name must match exactly and a new field to indicate
that the PID must be 022c. Being in the table will effectively disable
the counterproductive Fn key handling because fnmode=2 is equivalent
to fnmode=0 on the Omoton.
I will send a new patch.
-Alex
next prev parent reply other threads:[~2025-02-24 2:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-01 5:51 [PATCH] HID: apple: fix up the F6 key on the Omoton KB066 keyboard Alex Henrie
2025-01-17 6:12 ` [PATCH resend] " Alex Henrie
2025-02-03 21:57 ` Jiri Kosina
2025-02-05 3:02 ` Alex Henrie
2025-02-07 13:07 ` Jiri Kosina
2025-02-12 17:36 ` Aditya Garg
2025-02-12 17:43 ` Aditya Garg
2025-02-16 1:08 ` Alex Henrie
2025-02-16 6:06 ` Aditya Garg
2025-02-16 6:45 ` Aditya Garg
2025-02-17 4:13 ` Alex Henrie
2025-02-17 5:18 ` Aditya Garg
2025-02-17 6:42 ` Alex Henrie
2025-02-17 10:02 ` Aditya Garg
2025-02-17 10:03 ` Aditya Garg
2025-02-24 2:50 ` Alex Henrie [this message]
2025-02-24 4:44 ` Alex Henrie
2025-02-24 5:05 ` Aditya Garg
2025-02-24 5:18 ` Alex Henrie
2025-02-24 5:30 ` Aditya Garg
2025-02-24 5:40 ` Alex Henrie
2025-02-24 5:46 ` Aditya Garg
2025-02-24 6:01 ` Alex Henrie
2025-02-24 2:46 ` Alex Henrie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMMLpeRg8RhncwwK7yyJsT=8Q7221euMA7=-mySN3YLFpWPQjQ@mail.gmail.com' \
--to=alexhenrie24@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=gargaditya08@live.com \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).