Re: fn-key issue with hid_apple and keychron keyboards

Hi Bastian,

On 5/17/21 9:46 AM, Bastian Venthur wrote:

Hello Hans,

I'm writing you because apparently you provided the patch [1] for Linux "Disable Fn-key key-re-mapping on clone keyboards" -- which seems related to a bug I've found with Keychron C1 keyboard.

I'm really sorry if you're not the right contact for those kind of issues, and would be very happy if you could point me to the correct ones.

It is usually a good idea to at least Cc the relevant linux mailinglist on
questions like this. I've added the linux-input list to the Cc now.

I recently got a Keychron C1 keyboard (but I gather, other Keyboards from this company are affected as well). The keyboard has a physical switch for "Windows" and "Mac" modes, however in both cases the kernel recognizes it as an Apple keyboard and loads the "hid-apple" module. However it does *not* recognize the 'Fn' key and disables it. But the keyboard has one and I have to enable it manually either via:

# as root:
echo 2 > /sys/module/hid_apple/parameters/fnmode

or permanently:

options hid_apple fnmode=2
in /etc/modprobe.d/hid_apple.conf

Without this, I cannot use the Function-keys, they will always be used as Multimedia-keys, regardless if you press Fn + F1 or not.

Here's the relevant dmesg output when i plug the keyboard in.

[    6.234069] apple 0003:05AC:024F.0004: input,hidraw3: USB HID v1.11 Keyboard [Keychron Keychron C1] on usb-0000:06:00.4-1.2.1.2/input0
[    6.234261] apple 0003:05AC:024F.0005: Fn key not found (Apple Wireless Keyboard clone?), disabling Fn key handling
[    6.294181] apple 0003:05AC:024F.0005: input,hidraw4: USB HID v1.11 Keyboard [Keychron Keychron C1] on usb-0000:06:00.4-1.2.1.2/input1

Ok, so the keyboard presents itself as 2 interfaces. and the "Fn key not found" message
is only being printed for the second interface. So I guess that the trouble F1-F12 keys
are actually coming out of the first interface (the 0003:05AC:024F.0004 device above).

What my patch does it completely disables the fnmode handling, similar to setting the
fnmode parameter to 0, but unlike my (Maxxter KB-BT-001 Bluetooth keyboard) "clone" your
keyboard does actually advertise a Mac style Fn key in its descriptors, at least for the
first interface so it is treated as a standard Mac keyboard where the non Fn behavior of
the F-keys is to send the multimedia events. Normally pressing Fn + F1 - F-12 should then
result in the kernel actually sending F1-F12 and setting fnmode=2 should just invert when
you need to press Fn.

Basically the way the actual mac keyboards work is the simply always send F1 - F12 events
and a separate Fn event and leave it up to the OS to translate this to either plain
F1 - F12 or to the multimedia codes. Where as normal keyboards handle the Fn press
internally and actually send different "scancodes" over the wire to the computer when
Fn + F1 - F12 is pressed.

But if I understand you correctly then the Fn translation hid-apple is doing to make
things work as expected with Mac keyboards is not working for you, IOW with fnmode=1
pressing Fn + F1 does not result in F1 being send, correct ?  This means that your
keyboard behaves more like a normal keyboard instead of as an apple keyboard.

I also wonder if the Fn key sends any events at all (or if it is fully handled internally)...

I have no idea how to fix this, but I can provide additional information if needed.

Please become root ("sudo su -") and then do:

/sys/kernel/debug/hid/0003:05AC:024F.*/rdesc > Keychron-C1-rdesc

And attach the generated Keychron-C1-rdesc file to your next email.

Also please as root run:

sudo evemu-record

And then select the device belonging to your keyboard and press F1, Fn and Fn + F1,
please repeat this for all input devices belonging to your keyboard and then
copy and paste the output of each run into your next email.

Regards,

Hans

Hi Hans, thanks for your reply and Cc'ing the correct list!


Please note, for this test I have:
* set fnmode=2 to make the fkeys work properly
* the keyboard has a physical switch for Mac and Windows, I have set it
  to Windows
please let me know if i should change fnmode and/or test with the Mac setting on.

[...]

I also wonder if the Fn key sends any events at all (or if it is fully handled internally)...

quoted

I have no idea how to fix this, but I can provide additional information if needed.

Please become root ("sudo su -") and then do:

/sys/kernel/debug/hid/0003:05AC:024F.*/rdesc > Keychron-C1-rdesc

And attach the generated Keychron-C1-rdesc file to your next email.

That does not work, even as root I get "permission denied"

# /sys/kernel/debug/hid/0003\:05AC\:024F.0004/rdesc
-bash: /sys/kernel/debug/hid/0003:05AC:024F.0004/rdesc: Permission denied
# /sys/kernel/debug/hid/0003\:05AC\:024F.0005/rdesc
-bash: /sys/kernel/debug/hid/0003:05AC:024F.0005/rdesc: Permission denied

Also please as root run:

sudo evemu-record

And then select the device belonging to your keyboard and press F1, Fn and Fn + F1,
please repeat this for all input devices belonging to your keyboard and then
copy and paste the output of each run into your next email.

Here's the evemu-record output for the first device. I pressed F1, Fn, and Fn+F1 as requested, however only the F1 key produced output. Fn did nothing and Fn+F1 decreased the display backlight but didn't produce output. You also seem to see my CTRL+C to quit:


Select the device event number [0-21]: 20
# EVEMU 1.3
# Kernel: 5.10.0-6-amd64
# DMI: dmi:bvnLENOVO:bvrR1CET61W(1.30):bd12/21/2020:br1.30:efr1.30:svnLENOVO:pn20UHS0G000:pvrThinkPadT14sGen1:rvnLENOVO:rn20UHS0G000:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
# Input device name: "Keychron Keychron C1"
# Input device ID: bus 0x03 vendor 0x5ac product 0x24f version 0x111
# Supported events:
#   Event type 0 (EV_SYN)
#     Event code 0 (SYN_REPORT)
#     Event code 1 (SYN_CONFIG)
#     Event code 2 (SYN_MT_REPORT)
#     Event code 3 (SYN_DROPPED)
#     Event code 4 ((null))
#     Event code 5 ((null))
#     Event code 6 ((null))
#     Event code 7 ((null))
#     Event code 8 ((null))
#     Event code 9 ((null))
#     Event code 10 ((null))
#     Event code 11 ((null))
#     Event code 12 ((null))
#     Event code 13 ((null))
#     Event code 14 ((null))
#     Event code 15 (SYN_MAX)
#   Event type 1 (EV_KEY)
#     Event code 1 (KEY_ESC)
#     Event code 2 (KEY_1)
#     Event code 3 (KEY_2)
#     Event code 4 (KEY_3)
#     Event code 5 (KEY_4)
#     Event code 6 (KEY_5)
#     Event code 7 (KEY_6)
#     Event code 8 (KEY_7)
#     Event code 9 (KEY_8)
#     Event code 10 (KEY_9)
#     Event code 11 (KEY_0)

558 more lines

Hi Bastian,

On 5/17/21 1:08 PM, Bastian Venthur wrote:

Hi Hans, thanks for your reply and Cc'ing the correct list!


Please note, for this test I have:
* set fnmode=2 to make the fkeys work properly
* the keyboard has a physical switch for Mac and Windows, I have set it
  to Windows
please let me know if i should change fnmode and/or test with the Mac setting on.

[...]

quoted

I also wonder if the Fn key sends any events at all (or if it is fully handled internally)...

quoted

I have no idea how to fix this, but I can provide additional information if needed.

Please become root ("sudo su -") and then do:

/sys/kernel/debug/hid/0003:05AC:024F.*/rdesc > Keychron-C1-rdesc

quoted

And attach the generated Keychron-C1-rdesc file to your next email.

That does not work, even as root I get "permission denied"

# /sys/kernel/debug/hid/0003\:05AC\:024F.0004/rdesc
-bash: /sys/kernel/debug/hid/0003:05AC:024F.0004/rdesc: Permission denied
# /sys/kernel/debug/hid/0003\:05AC\:024F.0005/rdesc
-bash: /sys/kernel/debug/hid/0003:05AC:024F.0005/rdesc: Permission denied

Ok, this means you are likely running with secure-boot enabled on a somewhat
older kernel where /sys/kernel/debug (aka debugfs) gets completely disabled.

Can you try (temporarily) disabling secure boot in your BIOS, that should fix
things (otherwise there are other ways to get the descriptors but in my
experience this way is the easiest)

quoted

Also please as root run:

sudo evemu-record

And then select the device belonging to your keyboard and press F1, Fn and Fn + F1,
please repeat this for all input devices belonging to your keyboard and then
copy and paste the output of each run into your next email.

Here's the evemu-record output for the first device. I pressed F1, Fn, and Fn+F1 as requested, however only the F1 key produced output. Fn did nothing and Fn+F1 decreased the display backlight but didn't produce output. You also seem to see my CTRL+C to quit:


Select the device event number [0-21]: 20
# EVEMU 1.3
# Kernel: 5.10.0-6-amd64
# DMI: dmi:bvnLENOVO:bvrR1CET61W(1.30):bd12/21/2020:br1.30:efr1.30:svnLENOVO:pn20UHS0G000:pvrThinkPadT14sGen1:rvnLENOVO:rn20UHS0G000:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
# Input device name: "Keychron Keychron C1"
# Input device ID: bus 0x03 vendor 0x5ac product 0x24f version 0x111
# Supported events:
#   Event type 0 (EV_SYN)
#     Event code 0 (SYN_REPORT)
#     Event code 1 (SYN_CONFIG)
#     Event code 2 (SYN_MT_REPORT)
#     Event code 3 (SYN_DROPPED)
#     Event code 4 ((null))
#     Event code 5 ((null))
#     Event code 6 ((null))
#     Event code 7 ((null))
#     Event code 8 ((null))
#     Event code 9 ((null))
#     Event code 10 ((null))
#     Event code 11 ((null))
#     Event code 12 ((null))
#     Event code 13 ((null))
#     Event code 14 ((null))
#     Event code 15 (SYN_MAX)
#   Event type 1 (EV_KEY)
#     Event code 1 (KEY_ESC)
#     Event code 2 (KEY_1)
#     Event code 3 (KEY_2)
#     Event code 4 (KEY_3)

560 more quoted lines

Ok, so as suspected your keyboard behaves as a normal (non-apple) keyboard
using separate (multimedia related) scancodes when using Fn + F1 - F12, in this
case even reporting them on a second interface (likely because the first
interface is implementing the USB kbd boot protocol to make the kbd work inside
the BIOS setup menu).

Which means that your keyboard really should just be handled by a the standard
hid-input driver rather then being handled by the special hid-apple driver.

Now if only it would have not "hijacked" Apple's USB vendor and product id and
would just have used their own then everything would just work.

IOW this is another clone like the Maxxter kbd I added, but the current
clone-detection code is not detecting it (at least not for the first of
the usb interfaces which it has).

Just to make sure I'm not missing anything, can you redo the evemu-record
tests with the switch set to mac mode. And when you gather the rdesc files
can you do that twice too, once in windows mode and once in mac mode ?

Please unplug and replug the keyboard after changing the switch to make
sure that Linux sees the changed descriptors (assuming they change at all).

Regards,

Hans

Hi Hans,

On 17.05.21 16:26, Hans de Goede wrote:

quoted

# /sys/kernel/debug/hid/0003\:05AC\:024F.0004/rdesc
-bash: /sys/kernel/debug/hid/0003:05AC:024F.0004/rdesc: Permission denied
# /sys/kernel/debug/hid/0003\:05AC\:024F.0005/rdesc
-bash: /sys/kernel/debug/hid/0003:05AC:024F.0005/rdesc: Permission denied

Ok, this means you are likely running with secure-boot enabled on a somewhat
older kernel where /sys/kernel/debug (aka debugfs) gets completely disabled.

Can you try (temporarily) disabling secure boot in your BIOS, that should fix
things (otherwise there are other ways to get the descriptors but in my
experience this way is the easiest)

Sorry, I've tried booting with secure boot disabled in the BIOS, but with the same result. So I guess we have to get that info the hard way.

[...]

Ok, so as suspected your keyboard behaves as a normal (non-apple) keyboard
using separate (multimedia related) scancodes when using Fn + F1 - F12, in this
case even reporting them on a second interface (likely because the first
interface is implementing the USB kbd boot protocol to make the kbd work inside
the BIOS setup menu).

Which means that your keyboard really should just be handled by a the standard
hid-input driver rather then being handled by the special hid-apple driver.

Now if only it would have not "hijacked" Apple's USB vendor and product id and
would just have used their own then everything would just work.

IOW this is another clone like the Maxxter kbd I added, but the current
clone-detection code is not detecting it (at least not for the first of
the usb interfaces which it has).

Just to make sure I'm not missing anything, can you redo the evemu-record
tests with the switch set to mac mode. And when you gather the rdesc files
can you do that twice too, once in windows mode and once in mac mode ?

Please unplug and replug the keyboard after changing the switch to make
sure that Linux sees the changed descriptors (assuming they change at all).

Sure, here we go this time with keyboard in Mac mode:

Select the device event number [0-21]: 11
# EVEMU 1.3
# Kernel: 5.10.0-6-amd64
# DMI: dmi:bvnLENOVO:bvrR1CET61W(1.30):bd12/21/2020:br1.30:efr1.30:svnLENOVO:pn20UHS0G000:pvrThinkPadT14sGen1:rvnLENOVO:rn20UHS0G000:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
# Input device name: "Keychron Keychron C1"
# Input device ID: bus 0x03 vendor 0x5ac product 0x24f version 0x111
# Supported events:
#   Event type 0 (EV_SYN)
#     Event code 0 (SYN_REPORT)
#     Event code 1 (SYN_CONFIG)
#     Event code 2 (SYN_MT_REPORT)
#     Event code 3 (SYN_DROPPED)
#     Event code 4 ((null))
#     Event code 5 ((null))
#     Event code 6 ((null))
#     Event code 7 ((null))
#     Event code 8 ((null))
#     Event code 9 ((null))
#     Event code 10 ((null))
#     Event code 11 ((null))
#     Event code 12 ((null))
#     Event code 13 ((null))
#     Event code 14 ((null))
#     Event code 15 (SYN_MAX)
#   Event type 1 (EV_KEY)
#     Event code 1 (KEY_ESC)
#     Event code 2 (KEY_1)
#     Event code 3 (KEY_2)
#     Event code 4 (KEY_3)
#     Event code 5 (KEY_4)
#     Event code 6 (KEY_5)
#     Event code 7 (KEY_6)
#     Event code 8 (KEY_7)
#     Event code 9 (KEY_8)
#     Event code 10 (KEY_9)
#     Event code 11 (KEY_0)
#     Event code 12 (KEY_MINUS)

567 more lines

Hi,

On 5/17/21 4:47 PM, Bastian Venthur wrote:

Hi Hans,

On 17.05.21 16:26, Hans de Goede wrote:

quoted

quoted

# /sys/kernel/debug/hid/0003\:05AC\:024F.0004/rdesc
-bash: /sys/kernel/debug/hid/0003:05AC:024F.0004/rdesc: Permission denied
# /sys/kernel/debug/hid/0003\:05AC\:024F.0005/rdesc
-bash: /sys/kernel/debug/hid/0003:05AC:024F.0005/rdesc: Permission denied

Ok, this means you are likely running with secure-boot enabled on a somewhat
older kernel where /sys/kernel/debug (aka debugfs) gets completely disabled.

Can you try (temporarily) disabling secure boot in your BIOS, that should fix
things (otherwise there are other ways to get the descriptors but in my
experience this way is the easiest)

Sorry, I've tried booting with secure boot disabled in the BIOS, but with the same result. So I guess we have to get that info the hard way.

Ah, I see. But I don't think I need a descriptor-dump anymore anyways,
see below.

[...]

quoted

Ok, so as suspected your keyboard behaves as a normal (non-apple) keyboard
using separate (multimedia related) scancodes when using Fn + F1 - F12, in this
case even reporting them on a second interface (likely because the first
interface is implementing the USB kbd boot protocol to make the kbd work inside
the BIOS setup menu).

Which means that your keyboard really should just be handled by a the standard
hid-input driver rather then being handled by the special hid-apple driver.

Now if only it would have not "hijacked" Apple's USB vendor and product id and
would just have used their own then everything would just work.

IOW this is another clone like the Maxxter kbd I added, but the current
clone-detection code is not detecting it (at least not for the first of
the usb interfaces which it has).

Just to make sure I'm not missing anything, can you redo the evemu-record
tests with the switch set to mac mode. And when you gather the rdesc files
can you do that twice too, once in windows mode and once in mac mode ?

Please unplug and replug the keyboard after changing the switch to make
sure that Linux sees the changed descriptors (assuming they change at all).

Sure, here we go this time with keyboard in Mac mode:

Select the device event number [0-21]: 11
# EVEMU 1.3
# Kernel: 5.10.0-6-amd64
# DMI: dmi:bvnLENOVO:bvrR1CET61W(1.30):bd12/21/2020:br1.30:efr1.30:svnLENOVO:pn20UHS0G000:pvrThinkPadT14sGen1:rvnLENOVO:rn20UHS0G000:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
# Input device name: "Keychron Keychron C1"
# Input device ID: bus 0x03 vendor 0x5ac product 0x24f version 0x111
# Supported events:
#   Event type 0 (EV_SYN)
#     Event code 0 (SYN_REPORT)
#     Event code 1 (SYN_CONFIG)
#     Event code 2 (SYN_MT_REPORT)
#     Event code 3 (SYN_DROPPED)
#     Event code 4 ((null))

586 more quoted lines

Thank you for the logs and sorry for being so slow to respond.

So looking at your evemu-record output, the keyboard is actually
behaving like a real Apple keyboard when put in Mac. mode.

This means that you should be able to send a "F1" keypress without
specifying any module parameter at all by pressing "Fn + F1" when
the keyboard is in Mac mode.

IOW in Mac mode everything should work fine, except that you may not
like the default behavior of F1-F12 being to send "multi-media" key
events instead of just plain "F1" - "F12" (and that you can change
with the fnmode=2 module parameter).

Since the keyboard is also using an Apple vendor- + product-id code
when in PC mode, things won't work as well in PC mode though since
then the "Fn" key likely does not actually send an event to the
machine to which the kbd is connected, causing the keys to be
stuck in "multi-media" mode regardless of the Fn key state
since when Fn is not pressed this is the default behavior and when
Fn is pressed then the key-press gets reported on the second
interface / device as a multi-media key-press.

This is really all the fault of the kbd-manufacturer, it should
really use different (non Apple) vendor- + product-ids when in
PC mode.

So the reason why I asked for the descriptors is to see if there
was some way to distuingish this keyboard from real Apple
keyboards, but I've already found a way to do that:

# Properties:
N: Keychron Keychron C1

The "Keychron Keychron C1" here comes from the USB device
strings; and we can use that to tell that we are dealing with
this Apple clone.

So now the question becomes what to do with this info though.
As I already said, I believe that in "Mac" mode all is working as
it should.  The problem is the "PC mode", the only thing which
I can come up with is to make fnmode=2 the default on this keyboard,
since that will also work in Mac mode (albeit different as on real
Mac keyboards) while also working in PC mode.

Does anyone (including you, Bastian) has any opinion on making
fnmode=2 the default on this keyboard model ?

Regards,

Hans

Hi Hans et al,


On 23.06.21 16:16, Hans de Goede wrote:
[...]

Thank you for the logs and sorry for being so slow to respond.

no worries, thank you for working on that issue.

So looking at your evemu-record output, the keyboard is actually
behaving like a real Apple keyboard when put in Mac. mode.

This means that you should be able to send a "F1" keypress without
specifying any module parameter at all by pressing "Fn + F1" when
the keyboard is in Mac mode.

IOW in Mac mode everything should work fine, except that you may not
like the default behavior of F1-F12 being to send "multi-media" key
events instead of just plain "F1" - "F12" (and that you can change
with the fnmode=2 module parameter).

Since the keyboard is also using an Apple vendor- + product-id code
when in PC mode, things won't work as well in PC mode though since
then the "Fn" key likely does not actually send an event to the
machine to which the kbd is connected, causing the keys to be
stuck in "multi-media" mode regardless of the Fn key state
since when Fn is not pressed this is the default behavior and when
Fn is pressed then the key-press gets reported on the second
interface / device as a multi-media key-press.

This is really all the fault of the kbd-manufacturer, it should
really use different (non Apple) vendor- + product-ids when in
PC mode.

So the reason why I asked for the descriptors is to see if there
was some way to distuingish this keyboard from real Apple
keyboards, but I've already found a way to do that:

quoted

# Properties:
N: Keychron Keychron C1

The "Keychron Keychron C1" here comes from the USB device
strings; and we can use that to tell that we are dealing with
this Apple clone.

So now the question becomes what to do with this info though.
As I already said, I believe that in "Mac" mode all is working as
it should.  The problem is the "PC mode", the only thing which
I can come up with is to make fnmode=2 the default on this keyboard,

5 more quoted lines

If i understand you correctly, you're saying you cannot make the fnmode depend on the Mac- or PC-mode that the keyboard is currently running on? I mean that would be of course the best solution, but if that is not possible I'd prefer the fnmode=2 switched on by default as this is not a Mac keyboard AND this is not an Apple operating system.


Thanks again Hans and take care,

Bastian

Hi Hans et al,


any updates on this one?


Cheers,

Bastian

On 24.06.21 09:35, Bastian Venthur wrote:

On 23.06.21 16:16, Hans de Goede wrote:

quoted

Does anyone (including you, Bastian) has any opinion on making
fnmode=2 the default on this keyboard model ?

If i understand you correctly, you're saying you cannot make the fnmode depend on the Mac- or PC-mode that the keyboard is currently running on? I mean that would be of course the best solution, but if that is not possible I'd prefer the fnmode=2 switched on by default as this is not a Mac keyboard AND this is not an Apple operating system.

Hi Bastian,

On 8/27/21 9:39 AM, Bastian Venthur wrote:

Hi Hans et al,


any updates on this one?

I'm afraid not, this is still on my todo list, but there are a bunch of
higher priority things on there, so I'm not sure when I will get around
to this.

On 24.06.21 09:35, Bastian Venthur wrote:

quoted

On 23.06.21 16:16, Hans de Goede wrote:

quoted

Does anyone (including you, Bastian) has any opinion on making
fnmode=2 the default on this keyboard model ?

If i understand you correctly, you're saying you cannot make the fnmode depend on the Mac- or PC-mode that the keyboard is currently running on? I mean that would be of course the best solution, but if that is not possible I'd prefer the fnmode=2 switched on by default as this is not a Mac keyboard AND this is not an Apple operating system.

Right, there is no way to detect if the keyboard is in Mac- or PC-mode, so the plan would be to make fnmode=2 the default for this "Mac clone" (mac USB-ids (ab)using) keyboard.

Regards,

Hans

On 8/30/21 11:24 AM, Hans de Goede wrote:

Hi Bastian,

On 8/27/21 9:39 AM, Bastian Venthur wrote:

quoted

Hi Hans et al,


any updates on this one?

I'm afraid not, this is still on my todo list, but there are a bunch of
higher priority things on there, so I'm not sure when I will get around
to this.

p.s.

If you know C (the programming language) you could try to make the change
yourself, I can give you some pointers where to get started.

 

quoted

On 24.06.21 09:35, Bastian Venthur wrote:

quoted

On 23.06.21 16:16, Hans de Goede wrote:

quoted

Does anyone (including you, Bastian) has any opinion on making
fnmode=2 the default on this keyboard model ?

If i understand you correctly, you're saying you cannot make the fnmode depend on the Mac- or PC-mode that the keyboard is currently running on? I mean that would be of course the best solution, but if that is not possible I'd prefer the fnmode=2 switched on by default as this is not a Mac keyboard AND this is not an Apple operating system.

Right, there is no way to detect if the keyboard is in Mac- or PC-mode, so the plan would be to make fnmode=2 the default for this "Mac clone" (mac USB-ids (ab)using) keyboard.

Regards,

Hans

Hi Hans et al,

I've noticed that the issue has been fixed by now: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa33382c7f74a1444f90f324007da1431d7180b2

Thank you and whoever else was involved very much for your work!


Cheers,

Basti

Am 30.08.21 um 11:25 schrieb Hans de Goede:

On 8/30/21 11:24 AM, Hans de Goede wrote:

quoted

Hi Bastian,

On 8/27/21 9:39 AM, Bastian Venthur wrote:

quoted

Hi Hans et al,


any updates on this one?

I'm afraid not, this is still on my todo list, but there are a bunch of
higher priority things on there, so I'm not sure when I will get around
to this.

p.s.

If you know C (the programming language) you could try to make the change
yourself, I can give you some pointers where to get started.

  

quoted

quoted

On 24.06.21 09:35, Bastian Venthur wrote:

quoted

On 23.06.21 16:16, Hans de Goede wrote:

quoted

Does anyone (including you, Bastian) has any opinion on making
fnmode=2 the default on this keyboard model ?

If i understand you correctly, you're saying you cannot make the fnmode depend on the Mac- or PC-mode that the keyboard is currently running on? I mean that would be of course the best solution, but if that is not possible I'd prefer the fnmode=2 switched on by default as this is not a Mac keyboard AND this is not an Apple operating system.

Right, there is no way to detect if the keyboard is in Mac- or PC-mode, so the plan would be to make fnmode=2 the default for this "Mac clone" (mac USB-ids (ab)using) keyboard.

Regards,

Hans

-- 
Bastian Venthur
https://venthur.de

Hi,

On 7/31/22 21:12, Bastian Venthur wrote:

Hi Hans et al,

I've noticed that the issue has been fixed by now: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa33382c7f74a1444f90f324007da1431d7180b2

Thank you and whoever else was involved very much for your work!

You're welcome and sorry that I did not get around to fixing
this myself sooner.

Regards,

Hans

Am 30.08.21 um 11:25 schrieb Hans de Goede:

quoted

On 8/30/21 11:24 AM, Hans de Goede wrote:

quoted

Hi Bastian,

On 8/27/21 9:39 AM, Bastian Venthur wrote:

quoted

Hi Hans et al,


any updates on this one?

I'm afraid not, this is still on my todo list, but there are a bunch of
higher priority things on there, so I'm not sure when I will get around
to this.

p.s.

If you know C (the programming language) you could try to make the change
yourself, I can give you some pointers where to get started.

 

quoted

quoted

On 24.06.21 09:35, Bastian Venthur wrote:

quoted

On 23.06.21 16:16, Hans de Goede wrote:

quoted

Does anyone (including you, Bastian) has any opinion on making
fnmode=2 the default on this keyboard model ?

If i understand you correctly, you're saying you cannot make the fnmode depend on the Mac- or PC-mode that the keyboard is currently running on? I mean that would be of course the best solution, but if that is not possible I'd prefer the fnmode=2 switched on by default as this is not a Mac keyboard AND this is not an Apple operating system.

Right, there is no way to detect if the keyboard is in Mac- or PC-mode, so the plan would be to make fnmode=2 the default for this "Mac clone" (mac USB-ids (ab)using) keyboard.

Regards,

Hans