search

free5lot / hid-apple-patched

Allows to swap the Fn key and left Control key and other tweaks on Macbook Pro and Apple keyboards in GNU/Linux
GNU General Public License v2.0
350 stars 61 forks source link

Only getting the default options after patch install. #67

Closed luis-alves closed 4 years ago

luis-alves commented 4 years ago

$ uname -a Linux name 5.6.11-arch1-1 #1 SMP PREEMPT Wed, 06 May 2020 17:32:37 +0000 x86_64 GNU/Linux Keyboard: Apple magic keyboard 2 (A1644)

1- I installed the hid-apple-patch through Arch AUR. 2- Ran sudo mkinitcpio -p linux 3- Rebooted But still only have these three options available: $ ls /sys/module/hid_apple/parameters/ fnmode iso_layout swap_opt_cmd

In hid_apple.conf the options are all in: cat /etc/modprobe.d/hid_apple.conf options hid_apple fnmode=2 options hid_apple swap_fn_leftctrl=0 options hid_apple swap_opt_cmd=1 options hid_apple rightalt_as_rightctrl=1 options hid_apple ejectcd_as_delete=1

I don't get any output from dkms status. I'm I missing something?

huseyin1419 commented 4 years ago

@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.

luis-alves commented 4 years ago

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

free5lot commented 4 years ago

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

vasilakisfil commented 4 years ago

@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 ?

luis-alves commented 4 years ago

@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!

vasilakisfil commented 4 years ago

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 ?

vasilakisfil commented 4 years ago

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

free5lot commented 4 years ago

@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.

bambinodino commented 4 years ago

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.

free5lot commented 4 years ago

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.

bambinodino commented 4 years ago

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...

free5lot commented 4 years ago

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.

bambinodino commented 4 years ago

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 https://github.com/free5lot/hid-apple-patched/issues/67#issuecomment-678392903, 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.

free5lot commented 4 years ago

@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?

free5lot commented 4 years ago

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: https://github.com/free5lot/hid-apple-patched/commit/e652e4511e6cf0aaeee8ce91e0282f6aee12affa

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 :)

free5lot commented 4 years ago

I found the source - it was mentioned by @almson here: https://github.com/free5lot/hid-apple-patched/issues/31#issuecomment-294473434

Aetf commented 4 years ago

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:

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.

free5lot commented 4 years ago

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.