linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bryan Cain <bryancain3@gmail.com>
To: linux-input@vger.kernel.org
Cc: Jiri Kosina <jikos@kernel.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Bryan Cain <bryancain3@gmail.com>
Subject: [PATCH 0/1] HID: apple: Properly handle function keys on Keychron keyboards
Date: Thu,  5 May 2022 13:12:20 -0600	[thread overview]
Message-ID: <20220505191221.36172-1-bryancain3@gmail.com> (raw)

Hi,

As the new owner of a Keychron C1 keyboard, I recently found this thread from
this mailing list (linux-input):

https://lore.kernel.org/all/897e57a9-38d8-c05f-ceed-01d486f02726@redhat.com/T/

To summarize the findings in that thread:
* Keychron keyboards (C-series and K-series) use the vendor:product IDs from a
  2009 Apple keyboard. When set to "Mac" mode, they actually do behave like
  that device, but in "Windows" mode, the Fn key doesn't generate a scancode,
  making it impossible to use F1-F12 when the fnmode parameter is set to its
  default value of 1.
* The universally accepted "fix" among Keychron owners online is to set
  fnmode=2 in /etc/modprobe.d/hid_apple.conf.
  (See https://gist.github.com/andrebrait/961cefe730f4a2c41f57911e6195e444)
* Keychron devices can be distinguished from Apple ones by the USB manufacturer
  string, but it's impossible for the kernel to programatically detect whether
  a Keychron keyboard is in "Windows" or "Mac" mode.

The thread arrives at a conclusion I agree with: that fnmode=2 should be the
default behavior for Keychron keyboards. But no one has actually implemented
this change yet, so I decided to do it myself.

My patch sets the default fnmode to the new value of 3, which behaves like
fnmode=2 for Keychron keyboards, and like the previous default of fnmode=1
for real Apple keyboards and any non-Keychron clones. This should produce
sensible behavior in all cases, including the corner case where someone plugs
a Keychron keyboard into their MacBook.

This change does mean that Keychron function keys in "Mac" mode won't default
to Apple-like behavior, but even in that case, both the Fn and non-Fn versions
of the keys are still usable. And as Bastian Venthur said in the thread linked
above, there's no particular reason for a user to expect Apple-like behavior
when using a non-Apple device with a non-Apple operating system.

This is my first time contributing to the kernel, so please let me know if I
need to do anything differently. Also, I don't have an Apple keyboard on hand
to test with, so I'd appreciate if someone could test my patch with one to
verify that their function key behavior is unchanged.

Regards,
Bryan


Bryan Cain (1):
  HID: apple: Properly handle function keys on Keychron keyboards

 drivers/hid/hid-apple.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

-- 
2.25.1


             reply	other threads:[~2022-05-05 19:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 19:12 Bryan Cain [this message]
2022-05-05 19:12 ` [PATCH 1/1] HID: apple: Properly handle function keys on Keychron keyboards Bryan Cain
2022-05-06  9:43   ` Hans de Goede
2022-05-06 10:04   ` Bastien Nocera
2022-05-11 12:22   ` Jiri Kosina
2022-05-09  7:02 ` [PATCH 0/1] " José Expósito

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=20220505191221.36172-1-bryancain3@gmail.com \
    --to=bryancain3@gmail.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=hdegoede@redhat.com \
    --cc=jikos@kernel.org \
    --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).