The linux header directory is going to differentiate between distros, I'm not entirely sure what the best route for guessing it within the makefile is. If anyone has an idea, I'll happily PR it if they're.. unable to somehow.

These changes don't need to go into this repo. They'd go into an Arch User Repository git repo (which would contain patches and the config files necessary to build a package for Arch). So no changes needed here. But I posted my experience since I'm not ready to contribute to AUR.

There's indeed an AUR package for this: https://aur.archlinux.org/packages/hid-apple-patched-git/

The maintainer doesn't update the PKGBUILD for a while. I have a more updated version at https://github.com/Aetf/PKGBUILDs/tree/master/hid-apple-patched-git

Thanks @Aetf

Added link to this topic to Readme.

The problems I described in the first post go away if the line DEST_MODULE_LOCATION='/kernel/drivers/hid' in dkms.conf is replaced with DEST_MODULE_LOCATION='/extra' and override hid-apple * extra is written to /etc/depmod.d/hid-apple.conf. The line MAKE="make LINUX_HEADER_DIR=/usr/src/linux-headers-${kernelver}" can also be deleted.

My dkms.conf:

BUILT_MODULE_NAME=hid-apple
DEST_MODULE_LOCATION='/extra'
PACKAGE_NAME=hid-apple
PACKAGE_VERSION=1.0
REMAKE_INITRD=yes
AUTOINSTALL=yes

If you can verify that it works on Ubuntu, then this can be the universal dkms.conf that works on all distributions.

@almson I'll look in about dkms soon, thank you.

@Aetf The text at ArchWiki about the patch is outdated, has broken links and etc:
https://wiki.archlinux.org/index.php/Apple_Keyboard#Swap_the_Fn_key_and_Left_Ctrl_key
Maybe the working version of module for Arch is this one? https://aur.archlinux.org/packages/hid-apple-patched-git-dkms/

Anyway, I hope someone of you, arch-guys, would be able to update ArchWiki.

@almson I checked your version of dkms.conf (without MAKE and different DEST_MODULE_LOCATION). Couldn't find out is the DEST_MODULE_LOCATION important in this case, but your /extra path works on Ubuntu 16.04.02 LTS, because it still places the module in the same place.

The small note

1. I tried to install with this new dkms.confinitially on the clean Ubuntu and it wasn't working after reboot, maybe I did something wrong, because I was playing with hid_apple.conf and Makefile too.
2. So I unistalled and removed this module, then I changed your dkms.conf back to stock one, and everything worked after reboot.
3. Then I uninstalled and removed and rebooted - as expected the default version of hid-apple was used.
4. I changed dkms.conf to yours again and installed again and it worked from there after reboot.

Now both dkms.conf work for me. A bit worried if there was or not some actual dkms.conf issue with the first installation or I did something wrong.

The dkms.conf file is changed in commit e652e45.
Feel free to add any feedback.

ArchWiki updated :)

@Aetf thank you!

@Aetf Thank you for your work!

A minor comment re AUR: Are you sure that it's best to make it a -git package? "-git" packages checkout master instead of a tag or commit and the package's version does not get updated. This means yaourt won't notify of upgrades, the AUR might break in the future, and (hypothetically) a malicious commit to GitHub will be sent to users. The alternative is to use source=("git+https://github.com/free5lot/$_pkgname#commit=${_commit}" and dropping the -git from the package name.

Also, with dkms.conf now being identical to the one that is in Git, it can be removed from the AUR.

@almson Thanks for the suggests on the AUR package. I'm using -git since we don't have a release here.

This means yaourt won't notify of upgrades

I can manually set the version to 0.0.0 in PKGBUILD, then AUR helpers like yaourt should notify upgrades every time it checks. I've adopted this in several other -git packages I maintained for a while (like openann-git) but haven't applied it to this one yet.

the AUR might break in the future

I'm not sure how not using -git package will help in this case?

(hypothetically) a malicious commit to GitHub will be sent to users. The alternative is to use source=("git+https://github.com/free5lot/$_pkgname#commit=${_commit}" and dropping the -git from the package name.

Using a specific commit won't solve the problem if we don't trust the upstream (this repo) at all. We still need to decided which commit to use in the PKGBUILD, and it adds lots of maintenance burden to update the PKGBUILD every time there's a new commit. Ultimately, this could be solved if @free5lot could provide signed releases. But don't you think it's a little bit overkill? :P

Also, I haven't seen any current packages on AUR using a specific commit for upstreams without a release. Is this a common practice?

Regarding to dkms.conf, I'm using hid-apple-patched for PACKAGE_NAME, which is different from the one in this repo. I remember I changed it to its current value for a reason, but I can't remember the details. I don't have much time for testing for now. So I just keep it as is. I'll update after I test if PACKAGE_NAME=hid-apple also works well.

@Aetf I think we're on the same page regarding the fact that a package that checkouts a specific commit/release has a number of advantages over a package that checkouts whatever commit is the latest. Ie, there won't be surprises.

I haven't seen any current packages on AUR using a specific commit for upstreams without a release. Is this a common practice?

I don't know. Maybe not. But it makes sense to me. This isn't a project that has many commits, so each commit is basically a release. Another way to look at it is the package maintainer is taking on the duty of declaring releases if the source maintainer chooses not to.

I can manually set the version to 0.0.0 in PKGBUILD, then AUR helpers like yaourt should notify upgrades every time it checks.

Recompiling a package on every yaourt -Syua sounds very annoying.

Checking AUR, I see a lot of -git packages which put the commit hash in the version string, but download the latest commit. (Example: https://aur.archlinux.org/packages/kodi-git/) Actually, I noticed this package does this as well. That makes no sense at all! kodi-git is already three commits ahead. Why is it named after yesterday's commit? Why not just put a date? Or a number that increments whenever the package maintainer notices updates? Or 0.0.0 if the source updates every day?

We still need to decided which commit to use in the PKGBUILD, and it adds lots of maintenance burden to update the PKGBUILD every time there's a new commit.

I wouldn't say lots, because of infrequent commits. It's the normal amount of burden. But it's obviously your call to make.

Using a specific commit won't solve the problem if we don't trust the upstream (this repo) at all.
@free5lot could provide signed releases

I may be a little unclear on this, but git is already cryptographically secure. If the package is set to point to a specific commit, that commit cannot be altered. If someone gets free5slot's Git credentials and makes a new commit that is malicious, the package maintainer can check the diff and not change the PKGBUILD. Signing is more for binary blobs.

Anyway, I'm sorry for making a fuss out of nothing. You can ignore this academic hair-splitting if you like. Thank you for making the package!

This is awesome, many thanks for your work. The patch works beautifully well, just make sure that:

• you have the linux headers installed in system
• the patch installs correctly
• permanent configuration is set in /etc/modprobe.d/hid_apple_pclayout.conf (not in /etc/modprobe.d/hid_apple.conf as stated in Configuration section)

Then reboot and go!

There's a couple gotchas with the AUR package that have to do with Arch itself.

• It's easy to forget to install kernel headers. I opened an issue https://bugs.archlinux.org/task/66048
• Installing this package won't rebuild initramfs. Unless user happens to also install or upgrade the linux package, they'll need to run sudo mkinitcpio -P all. I opened an issue https://bugs.archlinux.org/task/66050
• Package should name the conf file as hid_apple.conf to be consistent with README

The installation section in README is very much ubuntu specific. For Archlinux users, the ArchWiki has more specific instructions. Maybe the last section of links should appear early.

The Configuration section, not just the Installation section, mentions hid_apple.conf. Why do you not want to use that name?

In the wiki:

• You mention having to modify /etc/mkinitcpio.conf. I haven't found this necessary. Perhaps mkinitcpio picks up files in modprobe.d automatically?
• I think the "Change the Behavior Without Reboot" section is unnecessary and/or in the wrong place. I don't think it's dangerous, either. (It's dangerous if you've modified the source code and introduced a bug.)
• I think talking about "a patch" is confusing. (A patch is something you apply yourself to source code.) Just talk about the hid-apple-patched-git-dkms package.
• You should mention installing kernel headers.

To avoid file conflict with the existing config file when installing/updating the package. Users will likely need to modify the config file or include additional parameters. It's possible to create .pacsave automatically and avoid overwriting, but I think providing the default config file under a different name requires the least manual intervention when updating. In the future, I may move the default config file to /usr/lib/modprobe.d. But I need to test how it works and what are the loading orders of the config files.

You mention having to modify /etc/mkinitcpio.conf. I haven't found this necessary. Perhaps mkinitcpio picks up files in modprobe.d automatically?

Actually I'm not sure. My setup is slightly different: I have hid_apple added to MODULES array to load it during early boot, so even in the emergency shell keys are correctly swapped. So in my case, the config file definitely needs to be in initramfs. Perhaps if you don't early load the module, the config file doesn't need to be in initramfs?

Another possibility is you have modconf hook in your /etc/mkinitcpio.conf, which will automatically pick up config files.

I don't have time to verify this at the moment. If you are sure about it, feel welcome to update the wiki accordingly.

I think the "Change the Behavior Without Reboot" section is unnecessary and/or in the wrong place. I don't think it's dangerous, either. (It's dangerous if you've modified the source code and introduced a bug.)

That section applies to both un-apple-keyboard and hid-apple-patched. The warning still applies anyway. When I was experimenting with this, it happened multiple times where the current hid_apple module unloaded but modprobe hid_apple failed for various reasons, leaving an unusable system because both touchpad and keyboard are dead. Not everyone has a spare external keyboard at hand.

I think talking about "a patch" is confusing. (A patch is something you apply yourself to source code.) Just talk about the hid-apple-patched-git-dkms package.
You should mention installing kernel headers.

Fair points.

I don't think having two conflicting config files is a solution. The recommended way of managing config is to use pacman config management https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave https://wiki.archlinux.org/index.php/PKGBUILD#backup

I've figured out how to automatically trigger mkinitcpio.

Please take a look at my last 2 commits https://github.com/almson/hid-apple-patched-git-dkms/ I'm not sure how to make something like a pull request for AUR.

You guys are both more competent in Arch than I am, so I have not much to say in essence.

But I can propose one of you to make a small PR for README.md modification by adding small block "Installation on Arch Linux (via AUR)" with short instruction and link to arch wiki. We will place it just after "Installation via DKMS (recommended)". The possible reasoning is that Arch is a major distribution with users that are more likely to modify something that lowlevel than Ubuntu's.
Is this proposal good or not?

@Aetf Oops, I made a mistake with the link. Here is my AUR repo: https://github.com/almson/hid-apple-patched-git-dkms/

@almson

There are two separate issues being discussed here:

What should be the name of the config file and where to put it

After reading the documentation of modprobe, I'm now lean towards putting default config to /usr/lib/modprobe.d/hid_apple.conf, then the user can put their own tweaks in /etc/modprobe.d/hid_apple.conf.

I also checked the default /etc/mkinitcpio.conf provided by mkinitcpio package. It includes the modconf hook, so that's why it works for you without changing /etc/mkinitcpio.conf.

How to trigger mkinitcpio build after install/upgrade

As you said, there is no clean way to do it at the moment. I also thought about installing our own Pacman hook. But I thought the hook has no effect for first-time installs, no?

Actually, from the DKMS man page, I found an option REMAKE_INITRD, which is also set in my package and is supposed to trigger initramfs rebuild after installing the module. Apparently it doesn't work in Archlinux. I guess that's the issue and we probably should report that, rather than implementing our own hack.

I updated the package and I think it achieves what we want now:

• Package's default configuration files are installed to /usr/lib/modprobe.d/hid_apple.conf, users are free to override. See Arch wiki for more explanation.
• Since the modconf hook is included by default in mkinitcpio.conf, I made a new AUR package mkinitcpio-modconf-hook-git to provide a Pacman hook to trigger mkinitcpio on changes in /etc/modprobe.d/* and /usr/lib/modprobe.d/*. This IMHO is useful in general.
• I made this package (hid-apple-patched-git-dkms) depend on mkinitcpio-modconf-hook-git. This way, the hook will be installed before installing hid-apple-patched, and will work even on first-time installations.

@free5lot
I'll make a PR to update this repo's README tomorrow, pointing Arch users to Arch wiki. Already made the PR.

Thanks @Aetf , if everything is fine with everything I will close this issue as solved soon.

@Aetf I think using /usr/lib/modprobe.d/ is a good approach. I'm not sure it's the best approach, since it makes it less obvious what the settings are. The module has its own, documented defaults, which the package "secretly" overrides.

I don't think making another package which adds a hook on all changes to modprobe.d is a good idea. It's heavy-handed. Why do you think my approach doesn't work? I've tested it from a clean install.

Did you report the REMAKE_INITRD bug?

@almson

I think using /usr/lib/modprobe.d/ is a good approach. I'm not sure it's the best approach, since it makes it less obvious what the settings are. The module has its own, documented defaults, which the package "secretly" overrides.

It's pretty standard practice to put vendor-supplied config files (i.e. installed by packages) to /usr, while the system administrator (i.e. user in the case of the single-user desktop environment) have their config in /etc.

I also won't call it "secretly". This location is clearly stated both in the package post-installation message and in the Wiki. Are you saying the package should not provide any default configuration at all? It also makes sense to me.

I don't think making another package which adds a hook on all changes to modprobe.d is a good idea. It's heavy-handed. Why do you think my approach doesn't work? I've tested it from a clean install.

Sorry, I should have tested. Your approach does work from a clean install.

But I think the hook simply doesn't belong to this package, which is supposed to provide a kernel module. This rebuilding problem is not unique to us, any kernel module packages wishing to include modprobe.d config files will need to rebuild initramfs. If each has its own rebuild hook, the rebuild will run more times than necessary, opposite to the very idea of having pacman hook in the first place.

I'd argue that rebuilding initramfs on modprobe.d change is the desired behavior, given the modconf hook is included by default in /etc/mkinitcpio.conf. I actually consider it a bug to not including the hook with the 'mkinitcpio' package. That's the superior solution because any changes in kernel or config files will only result in one rebuild.

But given I'm quite tight on time budget at the moment to report and push for a fix in mkinitcpio, having the hook in a separate package is acceptable in the short term, giving other packages (if any) the possibility to depend on it and reduce unnecessary rebuilds.

Did you report the REMAKE_INITRD bug?

No I didn't. I'd really appreciate it if you could report that and/or the feature request to include the hook in mkinitcpio.

The problems I described in the first post go away if the line DEST_MODULE_LOCATION='/kernel/drivers/hid' in dkms.conf is replaced with DEST_MODULE_LOCATION='/extra' and override hid-apple * extra is written to /etc/depmod.d/hid-apple.conf. The line MAKE="make LINUX_HEADER_DIR=/usr/src/linux-headers-${kernelver}" can also be deleted.

@almson maybe there is an issue with DEST_MODULE_LOCATION='/extra'.
Please see #67 (comment)

Will DEST_MODULE_LOCATION='/kernel/../extra/' or DEST_MODULE_LOCATION='/kernel/extra/' work the same way as current /extra in Arch?
Because it will also concur with the documentation's requirements of starting with /kernel.