On 17 Feb 2025, at 9:43 AM, Alex Henrie [off-list ref] wrote:

On Sat, Feb 15, 2025 at 11:06 PM Aditya Garg [off-list ref] wrote:

quoted

In case I am wrong, can you share what exactly happens in each mode with fn on as well as off?

In fnmode=0 and fnmode=2, F1 and F2 are F1 and F2, and the rest are
special keys when Fn is not held and ordinary function keys when Fn is
held.

In fnmode=1, F1 and F2 are Brightness Down and Brightness Up, and the
rest are always special keys, although holding Fn changes some of the
special keys to different special keys.

In all modes, Home becomes Escape when Fn is held, Lock (which is
actually Power) becomes Delete when Fn is held, and F6 always sends a
reserved key code.

So judging from these observations:

1. Fn key is internal to the keyboard, and does not send KEY_FN like Apple Keyboards
2. F1 and F2 are broken as far as Fn translation is considered.
3. Since fnmode=0 shows the actual state of the keyboard, internal translation of rest keys is just fine.

This makes it impossible to fixup this keyboard since Fn is not there in raw HID reports.

We can then just make fnmode=0 as default for this keyboard, and optionally translate F1 and F2 permanently to media keys.

BTW, are there any differences in HID reports if Fn+F1 and only F1 are pressed?

On Sat, Feb 15, 2025 at 11:45 PM Aditya Garg [off-list ref] wrote:

quoted

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.

The trouble is, we have no way to read the state of the Omoton's Fn
key in software. The Fn key is entirely internal to the keyboard. I
even looked at the raw HID reports with and without Fn pressed, and
there is nothing. So either we translate F1 and F2 to Brightness Down
and Brightness Up (in fnmode=1) or we don't translate them at all (in
fnmode=0 and fnmode=2); we can't conditionally translate depending on
the Fn key.

But for all the other special keys, what you are saying makes sense
and is a good idea: In fnmode=0, we can translate all of the special
keys to be ordinary keys, and in fnmode=2, we can translate them to
their opposites. For example, if the keyboard sends Volume Down, in
fnmode=0 and fnmode=2 we'd translate it to F11 (because the keyboard
only sends Volume Down when Fn is not held), and if it sends F11, in
fnmode=2 we'd translate it to Volume Down (because the keyboard only
sends F11 when Fn is held).

My idea was based on the assumption that Fn is sending KEY_FN. Now, if my idea is implemented, the user would have to manually change the fnmod to switch between media and function keys, which is quite inconvenient, just because 2 keys are broken.

I would like to think it as fmode=0 with F1 and F2 broken because of manufacturing defect.

You also said F6 shows a reserved keycode, which IIRC, you sent in a patch to translate to F6. Is the keycode same with and without Fn? I am thinking of using this reserved keycode as a toggle key for the hid-apple driver to switch the modes between media and function keys.

quoted

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.

Let's please not change the special keys to be different from what
their labels show. For example, F3 is Search on the Omoton KB066 and
Scale on the Apple A1255. Personally I wouldn't even change Power to
Screen Lock to match its icon, although I'm okay with changing it if
others feel strongly.

In case you have an Apple A1255, could you check whether hdev->name is different from "Bluetooth Keyboard”. We don’t really want to break the original Apple version just because of this defective clone.