Package Details: hid-apple-patched-git-dkms 20170406.61dce7d-1

Git Clone URL: https://aur.archlinux.org/hid-apple-patched-git-dkms.git (read-only)
Package Base: hid-apple-patched-git-dkms
Description: Allows to swap the Fn key and left Control key on Macbook Pro and Apple keyboards in GNU/Linux (DKMS)
Upstream URL: https://github.com/free5lot/hid-apple-patched
Licenses: GPL2
Submitter: Aetf
Maintainer: Aetf
Last Packager: Aetf
Votes: 7
Popularity: 1.231676
First Submitted: 2017-04-17 15:14
Last Updated: 2017-04-17 15:14

Latest Comments

yubo56 commented on 2017-09-27 17:20

I'm getting that the `hid_apple_pclayout.conf` file doesn't work unless I put all the `options` on a single line, i.e.

```
options hid_apple fnmode=2 swap_fn_leftctrl=1 swap_opt_cmd=1 rightalt_as_rightctrl=1 ejectcd_as_delete=1
```

Anybody else see this? Not sure whether it's discussed somewhere, but if so, maybe the default conf file should be updated?

Edit: nvm, seems to be working fine now, not sure what happened

Aetf commented on 2017-04-17 15:04

I'll do the following to make the package DKMS-only:

1. update the current one to non-DKMS only, so the name is released
2. push the DKMS-only version under the name hid-apple-patched-git-dkms
3. file a merge request to merge the comments of the current one (hid-apple-patched-git) to hid-apple-patched-git-dkms.
4. add a pinned comment explaining the preference of DKMS version while the merge is not completed.

Edit:

Now the merge is completed.

Aetf commented on 2017-04-17 14:58

I'm glad to know DKMS works for you. Personally I use the DKMS version, and the non-DKMS one was just there when I adopted this package. I'm also thinking about dropping the non-DKMS version as it's hard to maintain.

Regarding dkms.conf, those lines seem to be Ubuntu related. Finally if the one bundled in upstream repo is usable [1], I'll use that one.

Enabling PC-like layout makes sense.

[1] https://github.com/free5lot/hid-apple-patched/issues/31

adfjjv commented on 2017-04-17 12:13

Also, the line `MAKE="make LINUX_HEADER_DIR=/usr/src/linux-headers-${kernelver}"` in dkms.conf seems to not be necessary. I guess it is set by DKMS automatically.

adfjjv commented on 2017-04-17 11:46

As far as I can tell, `linux-lts-headers` does not provide `linux-headers` either. As an example, package 'dkms' depends on all the header variants. The path `/usr/lib/modules/extramodules-4.9-` does not exist on my system, but `/usr/lib/extramodules-4.9.22-grsec/` does.

Anyway, I had good success with just using DKMS. By using your line `DEST_MODULE_LOCATION='/extra'` and copying your `/etc/depmod.d/hid-apple.conf`, it works even more smoothly. I suggest to make this package DKMS-only. Is there a reason to not use dkms?

P.S. the lines `CONFIG_MODULE_COMPRESS=yes CONFIG_MODULE_COMPRESS_GZIP=yes` in dkms.conf have no effect and should probably be removed. (These properties are not described by `man dkms` and the resulting module was not compressed.)

P.P.S. I think you should enable the PC-like layout automatically, since that is the goal of almost everyone who is installing this package.

Aetf commented on 2017-04-16 21:51

Hi @adfjjv,

I'm not familiar with `linux-gresec-headers`, but AFAIK, other variants of linux kernel headers has `provides=(linux-headers=...)` in their PKGBUILD, I'm not sure why this isn't the case for `linux-gresec`

For the module path, I believe `/usr/lib/modules/extramodules-4.9-` is the correct path as it's used by various official packages. [1,2,3] are a few I've found after a quick search for "kernel module".

Regarding the usage of uname, I agree that there's possibility to break. If you have better solution I'm happy to adopt. I thought about `$(pacman -Q linux | sed -r 's#.* ([0-9]+\.[0-9]+).*#\1#')`, but I suppose won't work for non-stock kernels.

The DKMS version installs kernel module to `modules/kernel_release/extra`, which also seems common for misc modules. This is configured in dkms.conf.

The bundled conf is installed to `/etc/modprobe.d/hid_apple.conf.example`, which will be ignored by default according to `man modprobe.d`.

[1] https://www.archlinux.org/packages/community/x86_64/acpi_call/
[2] https://www.archlinux.org/packages/community/x86_64/bbswitch/
[3] https://www.archlinux.org/packages/community/x86_64/r8168/

adfjjv commented on 2017-04-16 10:21

Doesn't work with `linux-grsec`. First, it depends on `linux-headers` but not `linux-grsec-headers`. Second, it calculates module path as `/usr/lib/modules/extramodules-4.9-` instead of `/lib/modules/extramodules-4.9.22-grsec/`. Third, using uname to build the path is dangerous, since it breaks when the kernel is updated but before the system is rebooted.

I'm not versed in DKMS packages, but plain DKMS at least doesn't run into the first two problems. Plain dkms has the problem of installing the module into `modules/${kernelver}/` instead of `modules/extramodules-.../`. How does this package do the correct thing?

Btw, `hid-apple-patched-dkms.install` includes comment "New functionalities are disabled by default.", which is incorrrect The bundled conf enables all of the new flags.

Aetf commented on 2017-04-10 19:36

Okay, now my repo on Github should be accessible to anyone.

For your question @j53c,

The PKGBUILD does correctly recognize your distro name. However, things may still be different for Manjaro to build kernel modules, i.e. filesystem layout & exact command to use & others. These are two different distro after all.

I suggest you first refer to Manjaro wiki for how to build kernel modules (whether to use dkms or not, or how to do that by hand, etc).

The pkgname array is a feature called split package, so with one makepkg run, you get two packages (w/ and w/o dkms). The error you got suggests the non-dkms version probably doesn't work for you. That's probably why @chronossc commented out the non-dkms one. You can try that and only build the dkms version, and see if that works for you.

j53c commented on 2017-04-10 19:09

Thanks for the quick response. I downloaded the tarball from the "Download snapshot" link above, extracted it and run makepkg.
This is what I get:
...
==> Extracting sources...
-> Creating working copy of hid-apple-patched git repo...
Reset branch 'makepkg'
==> Starting pkgver()...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
make: Entering directory '/usr/lib/modules/4.10.8-1-MANJARO/build'
make: *** No targets specified and no makefile found. Stop.
make: Leaving directory '/usr/lib/modules/4.10.8-1-MANJARO/build'
==> ERROR: A failure occurred in build().
Aborting...

After getting this error I checked the folder /usr/lib/modules/4.10.8-1-MANJARO/build and there is only one file there called vmlinux.

P.s. the reason why I thought PKGBUILD is not up to date is because I saw that 'hid-apple-patched-git' in pkgname is commented out in @chronossc patch, but not in the PKGBUILD that is in the tarball. I.e. the tarball has:
pkgname=( 'hid-apple-patched-git'
'hid-apple-patched-git-dkms')
and @chronossc patch has:
pkgname=( #'hid-apple-patched-git'
'hid-apple-patched-git-dkms')

So I'm not sure what is supposed to be. Though even when I adjusted PCKBUILD to look as @chronossc's patch it still doesn't compile. Hope this helps.

Aetf commented on 2017-04-10 18:34

Hi j53c, the latest PKGBUILD already contains the patch needed to build on Manjaro. You should be able to use whatever AUR helper you are using to directly download from AUR and build without error. Could you paste the exact error?

It's true that for now if you don't have an account on AUR with ssh private/public key setup you will get permission denied errors when doing submodule update. I'll fix those submodule urls once I get time. But anyway you don't need to clone my repo to get the latest PKGBUILD.

TL;DR: just download the latest snapshot from AUR and build with makepkg (if you are not familiar with any AUR helper), and then install one of the built package (dkms one or the other).

All comments