@luis-alves
I bought [ Apple Magic Keyboard 2, without numpad version, Turkish Q Layout ] two days ago.
I installed Arch Linux ( Turkish F Layout ) yesterday.
This module is working fine except two keys. [ + ] and [ < ] mixed.

LOG

# dkms status
hid-apple, 1.0, 5.6.15-arch1-1, x86_64: installed
hid-apple-patched, 20200410.d5ffaff, 5.6.15-arch1-1, x86_64: installed (original_module exists)

# ls /sys/module/hid_apple/parameters/
ejectcd_as_delete  fnmode  iso_layout  rightalt_as_rightctrl  swap_fn_leftctrl	swap_opt_cmd

# uname -a
Linux arch 5.6.15-arch1-1 #1 SMP PREEMPT Wed, 27 May 2020 23:42:26 +0000 x86_64 GNU/Linux

# cat /etc/modprobe.d/hid_apple.conf 
options hid_apple fnmode=2
options hid_apple swap_fn_leftctrl=1
options hid_apple swap_opt_cmd=1
options hid_apple rightalt_as_rightctrl=1
options hid_apple ejectcd_as_delete=1

Here is how I installed

# 1
pacman -S base-devel dkms linux-headers

# 2 This Aur package is dependency.
aur.archlinux.org/packages/mkinitcpio-modconf-hook-git/

# 3 I think Aur package is recommended way
aur.archlinux.org/packages/hid-apple-patched-git-dkms/

Note: I installed Aur packages with makepkg -si command. And I did not run mkinitcpio -p linux command. Aur package automaticly updates initramfs.

Thanks @ozdemir1419 . I tried one last thing: change the kernel to lts and got it to work.

@luis-alves so we can consider this installation issue to be solved?

@luis-alves I also installed that to a new laptop, running 20.04 pop_os:

Linux pop-os 5.4.0-7634-generic #38~1590707589~20.04~1dd0040-Ubuntu SMP Fri May 29 01:55:10 UTC  x86_64 x86_64 x86_64 GNU/Linux

I can also see only 3 parameters in /sys/module/hid_apple/parameters/ and needless to say that the ones missing, are not working.

Which kernel did you install and made it work ?

@vasilakisfil my kernel is: 5.4.43-1-MANJARO, don't forget to add kernel headers and restart.
@free5lot Yes the issue is closed by my part. Thanks for this tool and your time!

I updated the kernel to:

Linux pop-os 5.4.43-050443-generic #202005271238 SMP Wed May 27 16:42:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

and rebuild the module but no changes. Still seeing 3 options in parameters. any ideas ?

For some reason that I don't know, if I install it through the scripts (build.sh & install.sh) it works. Weird!

@vasilakisfil sorry, I have no idea.

For some reason that I don't know, if I install it through the scripts (build.sh & install.sh) it works.

Now we see that it's installation (so distro-related) problem, not about module itself. Though, I will keep this issue open for some time, maybe somebody will provide useful ideas or you will solve it yourself and describe the details.

I just upgraded to Linux Mint 20 on a MacBook Air when I realized my fn and ctrl keys were no longer swapped. So, I took the opportunity and updated to the latest version of the patch and ran into the same problem as @luis-alves described.

In dkms.conf the parameter DEST_MODULE_LOCATION is set to /extra. This will install the patched module alongside the originial module (if present). I changed that to /kernel/drivers/hid, the place where the original module lives inside /lib/modules/$(uname -r). The original module will be backed up by dkms, so it can be put back later, should one opt to remove the patched module using dkms.

Output from dkms install using the updated DEST_MODULE_LOCATION parameter:

Running module version sanity check.
 - Original module
   - Found /lib/modules/5.4.0-42-generic/kernel/drivers/hid/hid-apple.ko
   - Storing in /var/lib/dkms/hid-apple/original_module/5.4.0-42-generic/x86_64/
   - Archiving for uninstallation purposes
 - Installation
   - Installing to /lib/modules/5.4.0-42-generic/kernel/drivers/hid/

Before upgrading, the module was installed in /extra. That worked fine because kernel 4.15 in Linux Mint 19 did not contain the hid-apple module.

Thank you @bambinodino for this information!
Can you investigate what is the best approach and value for this DEST_MODULE_LOCATION option (that preferably would work for all distros) and make PR with this fix? So, that your input would be marked in the git log.

I guess the best value for DEST_MODULE_LOCATION is the location where the kernel itself would place the module, if known.

From man dkms:

DEST_MODULE_LOCATION[#]=
              This  directive  specifies the destination where a module should be installed to, once compiled.  It also is used for finding original_modules.  This is a required directive,
              except as noted below. This directive must start with the text "/kernel" which is in reference to /lib/modules/<kernelversion>/kernel.  Note that for  each  module  within  a
              dkms  package,  the numeric value of # must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering
              should start at 0 (eg. DEST_MODULE_LOCATION[0]="/kernel/drivers/something/" DEST_MODULE_LOCATION[1]="/kernel/drivers/other/").

              DEST_MODULE_LOCATION is ignored on Fedora and Red Hat Enterprise Linux, Novell SuSE Linux Enterprise Server 10 and higher, Novell SuSE Linux 10.0 and higher, and Ubuntu.  In‐
              stead, the proper distribution-specific directory is used.

I'm not sure if dkms has always been smart about finding and backing up original modules:

ORIGINAL MODULES
       During the first install of a module for a <kernelversion>, dkms will search /lib/modules/<kernelversion> for a pre-existing module of the same name. If one is found, it will  auto‐
       matically  be  saved  as  an "original_module" so that if the newer module is later removed, dkms will put the original module back in its place.  Currently, DKMS searches for these
       original modules with first preference going to modules located in /lib/modules/<kernelversion>/updates/ followed by $DEST_MODULE_LOCATION (as specified in dkms.conf ).  If one can‐
       not  be  found  in  either  location, a find will be used to locate one for that kernel.  If none are found, then during a later uninstall, your kernel will not have that module re‐
       placed.

       If more than one is found, then the first one located (by preference indicated above) will be considered the "original_module".  As well, all copies of the same-named module will be
       removed  from your kernel tree and placed into /var/lib/dkms/<module>/original_module/$kernelver/collisions so that they can be *manually* accessible later. DKMS will never actually
       do anything with the modules found underneath the /collisions directory, and they will be stored there until you manually delete them.

I had a look at what Arch Linux does in the AUR. They use /extra as the location for the module, installing it alongside the existing module. But they also deliver a custom /etc/depmod.d/hid-apple.conf, which tells depmod to prefer the module in /extra instead (see man 5 depmod.d):

override hid-apple * extra

The latter approach seems neater, since it doesn't replace existing modules. But it requires extra configuration. I suppose it comes down to personal preference...

So what's the best option here if we have one?
Omitting DEST_MODULE_LOCATION will break Arch and Mint, won't it? Setting it to /kernel/drivers/hid will make Mint work but break Arch? I don't get what the silver bullet is here.
Maintaining several dkms versions does not look great, does it?
I would like an advice from one who understands the best practices with cross-distrib dkms configs here.

Mint will work with DEST_MODULE_LOCATION set to /extra. But it will require an extra configuration file to be created by the user or package maintainer. I just tried it myself with the module installed to /extra. I created /etc/depmod.d/hid-apple.conf as described in #67 (comment), the way the Arch package maintainer does. The configuration file needs to be there before the module is installed using dkms.

Using /extra in conjunction with /etc/depmod.d/hid-apple.conf should work with most distributions and their respective packaging policies. So, the documentation needs to be amended and all should work fine, whether the kernel in use comes with its own hid-apple module or not.

@bambinodino and others, maybe current /extra value is not valid?
I mean, the documentation states DEST_MODULE_LOCATION must start with /kernel.
Maybe something like that should be right?
DEST_MODULE_LOCATION='/kernel/../extra/'

@Aetf what do you think as an AUR package maintainer?

Well I also checked the history and DEST_MODULE_LOCATION was changed from '/kernel/drivers/hid' to '/extra' 3 years ago to support both Ubuntu (who ignores it) and Arch according to the commit:
e652e45

Not sure why did I do this actually. And why '/kernel/drivers/hid' was not working for Arch.
I request help from Arch users here :)

I found the source - it was mentioned by @almson here: #31 (comment)

I'm also not very knowledgeable of dkms. This package is my first dkms package anyway...

/kernel/drivers/hid will not work in Arch packages because packages aren't supposed to modify files owned by other packages (the original hid-apple modules is owned by the linux package).

The /extra indeed seems a little bit wired, but I've also seen it's been used elsewhere. Anyway, I take a look as a few other packages for their choices of DEST_MODULE_LOCATION:

• The Debian wiki uses /extra in their example: https://wiki.debian.org/KernelDKMS
• bcwc_pcie module for MBP's webcam also uses /extra
• the Arch official (in community repo) virtualbox-host-modules-dkms uses /kernel/misc
• However, virtualbox-host-modules-arch, which is a compiled version of virtualbox-host-modules-dkms for Arch stock kernel, explicitly places compiled modules in /extramodules
• Most packages in extra and community repo in Arch follows this: a -dkms version that installs to /kernel/whatever and a precompiled version installs to /extramodules

Also, we are in a very unique situation that we want to override an existing module of the same name in the kernel, while all the above packages are providing completely new modules.

So at the end of the day, I guess as long as dkms can successfully compile the module to the target location, this shouldn't matter? Because we can always use /etc/depmod.d/hid-apple.conf to specify where to find our version.

Thank you @Aetf for this situation review!
I also saw Debian example but they have a note that DEST_MODULE_LOCATION is not important in their case.

OK, let's keep /extra until someone will provide better option working for majority of distros.

PS. I added information about all this and depmod.d in the README.md documentation.
The issue can be considered solved and close but if someone has anything to add - feel free to do so here.