Fedora 24 on a MacBook Pro 11,5 – custom kernel

Running Fedora on my Macbook is really a joy, but the default installation comes with a few issues. Two of them really grind my gears:

People have created the above bug reports to the Fedora maintainers and have supplied patches to the kernel to remedy these issue. However, the fixes aren’t currently present in the kernel.

This post consists of two parts:

  1. Quick fix: Enable my Copr repository and install the patched kernel
  2. DIY: Apply a kernel module patch yourself and test it

I’ll be writing a separate post on how to build your own kernel RPM with the patches included.

Part One – Enable my Copr repository and install the patched kernel

The patched kernel you can download from my Copr repository is just a rebuild from the original Fedora kernel SRPM with the above patches applied.

Copr creates the repositories for me, which enable you to do this:

$ sudo dnf copr enable dkanbier/macbook-kernel
$ sudo dnf install kernel-4.7.9-200.dkanbier.fc24

Now reboot your machine with this kernel and you are good to go.

It might be a good idea to stop dnf from automatically update the kernel. Otherwise when Fedora releases a new kernel, you lose the patched one. Add the following to /etc/dnf/dnf.conf:

exclude=kernel*

That’s it!

I’m still searching for a way to automatically build new kernels as they are released by Fedora, so the “dkanbier” kernel is always matched by the most recent Fedora stable kernel. Until then it’s up to me to create a new patched kernel when Fedora releases a new kernel.

Part Two – Patch a kernel module and testing it

This part describes the steps you need to take to apply a patch to a kernel module. In this example we’ll use the brightness key patch from https://bugzilla.kernel.org/show_bug.cgi?id=105051#c32

First, let’s look at the raw patch from comment 32 on that bugzilla entry:

--- ubuntu/drivers/platform/x86/apple-gmux.c.orig	2016-05-29 15:39:28.553868416 +1000
+++ ubuntu/drivers/platform/x86/apple-gmux.c.orig	2016-05-29 15:42:06.709241427 +1000
@@ -583,6 +583,7 @@ 
 
 static struct pci_dev *gmux_get_io_pdev(void)
 {
+	struct pci_dev *igp = NULL, *dgp = NULL;
 	struct pci_dev *pdev = NULL;
 
 	while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev))) {
@@ -592,10 +593,19 @@ 
 		if (!(cmd & PCI_COMMAND_IO))
 			continue;
 
-		return pdev;
+                if (pdev->bus && pdev->bus->number > 0 && !dgp)
+                        dgp = pci_dev_get(pdev);
+                else if (pdev->bus && pdev->bus->number == 0 && !igp)
+                        igp = pci_dev_get(pdev);
+
 	}
 
-	return NULL;
+        if (dgp && !igp)
+                pr_warn("Found only discrete GPU %s, integrated GPU is hidden,"
+                                " unable to protect backlight behind VGA IO",
+                                pci_name(dgp));
+        pci_dev_put(dgp);
+        return igp;
 }
 
 static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)

This tells us we want to apply this code to the file apple-gmux.c.orig.

We need the kernel source RPM (SRPM) from our current kernel. These can be found on the koji website.

To find out the current kernel:

[root@localhost ~]# uname -a
Linux localhost.localdomain 4.7.9-200.fc24.x86_64 #1 SMP Thu Oct 20 14:26:16 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

In this case we need the SRPM for 4.7.9-200.fc24. Searching the koji page, we can find the SRPM on this page:

https://koji.fedoraproject.org/koji/buildinfo?buildID=811477

In your homedir, create a directory structure to install the SRPM in:

[dkanbier@localhost ~]$ mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

Now download the SRPM file and install it (as yourself, do not use root):

[dkanbier@localhost ~]$ wget https://kojipkgs.fedoraproject.org//packages/kernel/4.7.9/200.fc24/src/kernel-4.7.9-200.fc24.src.rpm
[dkanbier@localhost ~]$ rpm -ivh kernel-4.7.9-200.fc24.src.rpm

This will install several files in the rpmbuild directory structure we created earlier, I won’t go over all the contents in this part of the post. Instead we where hunting for the apple-gmux.c.orig file.

Please note that the file we actually looking for is called apple-gmux.c, not apple-gmux.c.orig as in the patch file. This was a backup made by the user who submitted the patch.

There will be a linux-4.7.tar.xz file in rpmbuild/SOURCES. The apple-gmux.c file is in there, let’s extract it:

[dkanbier@localhost ~]$ cd rpmbuild/SOURCES
[dkanbier@localhost SOURCES]$ tar -xvJf linux-4.7.tar.xz linux-4.7/drivers/platform/x86/apple-gmux.c
linux-4.7/drivers/platform/x86/apple-gmux.c

Now we have file that we need to apply the patch on.  Save the above patch in the SOURCES directory and apply it to the apple-gmux.c file:

 

[dkanbier@localhost SOURCES]$ wget -O apple-gmux.patch https://bugzilla.kernel.org/attachment.cgi?id=218051&action=diff&context=patch&collapsed=&headers=1&format=raw
[dkanbier@localhost SOURCES]$ patch -p1 linux-4.7/drivers/platform/x86/apple-gmux.c apple-gmux.patch 
patching file linux-4.7/drivers/platform/x86/apple-gmux.c
[dkanbier@localhost SOURCES]$

Now we have the patched source file of the module. To actually be able to test it we need to build the module and load it into the kernel.

To build the patched module, we need to create a Makefile in the directory which holds the module we want to build:

[dkanbier@localhost SOURCES]$ cd linux-4.7/drivers/platform/x86/
 [dkanbier@localhost x86]$ vi Makefile

Add this to the Makefile, replacing [TAB} with an actual TAB:

obj-m := apple-gmux.o

KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

default:
[TAB]$(MAKE) -C $(KDIR) M=$(PWD) modules

With the Makefile in place you can compile the module:

[dkanbier@localhost x86]$ make
 make -C /lib/modules/4.7.9-200.fc24.x86_64/build M=/home/dkanbier/rpmbuild/SOURCES/linux-4.7/drivers/platform/x86 modules
 make[1]: Entering directory '/usr/src/kernels/4.7.9-200.fc24.x86_64'
 CC [M] /home/dkanbier/rpmbuild/SOURCES/linux-4.7/drivers/platform/x86/apple-gmux.o
 Building modules, stage 2.
 MODPOST 1 modules
 CC /home/dkanbier/rpmbuild/SOURCES/linux-4.7/drivers/platform/x86/apple-gmux.mod.o
 LD [M] /home/dkanbier/rpmbuild/SOURCES/linux-4.7/drivers/platform/x86/apple-gmux.ko
 make[1]: Leaving directory '/usr/src/kernels/4.7.9-200.fc24.x86_64'
[dkanbier@localhost x86]$ ll
 total 964
 -rw-rw-r--. 1 dkanbier dkanbier 25961 Oct 26 15:58 apple-gmux.c
 -rw-rw-r--. 1 dkanbier dkanbier 467704 Oct 26 16:09 apple-gmux.ko
 -rw-rw-r--. 1 dkanbier dkanbier 532 Oct 26 16:09 apple-gmux.mod.c
 -rw-rw-r--. 1 dkanbier dkanbier 97208 Oct 26 16:09 apple-gmux.mod.o
 -rw-rw-r--. 1 dkanbier dkanbier 374528 Oct 26 16:09 apple-gmux.o
 -rw-rw-r--. 1 dkanbier dkanbier 138 Oct 26 16:09 Makefile
 -rw-rw-r--. 1 dkanbier dkanbier 89 Oct 26 16:09 modules.order
 -rw-rw-r--. 1 dkanbier dkanbier 0 Oct 26 16:09 Module.symvers

Time to test the module. Unload the current module and insert the one we just patched:

[dkanbier@localhost x86]$ sudo rmmod apple-gmux
[dkanbier@localhost x86]$ sudo insmod ./apple-gmux.ko

The brightness keys should be working now. Sometimes you only see the brightness logo on the screen without getting any changes to the actual brightness. This means we need a reboot, and to be sure the patched module gets loaded we need to move it to the appropiate location.

Modules are compressed by default on fedora, so let’s compress the module and replace the existing one.

[dkanbier@localhost x86]$ tar cvJf apple-gmux.ko.xz apple-gmux.ko
[dkanbier@localhost x86]$ cp /lib/modules/4.7.9-200.fc24.x86_64/kernel/drivers/platform/x86/apple-gmux.ko.xz apple-gmux.ko.xz.orig
[dkanbier@localhost x86]$ cp apple-gmux.ko.xz /lib/modules/4.7.9-200.fc24.x86_64/kernel/drivers/platform/x86/

Now reboot and your brightness keys should be working properly now.

 

2 thoughts on “Fedora 24 on a MacBook Pro 11,5 – custom kernel

  1. I just installed Fedora 25 on a Macbook Pro 11,3. The brightness control works fine from the live usb, but fails from the installed system. I assume the live is using this patch, but I don’t know how to confirm this. The source code isn’t included on the live iso. It also seems strange that they wouldn’t be using the same sources for the live and installed kernels.

Leave a Reply

Your email address will not be published. Required fields are marked *