acpi_ibm on later ThinkPad models

Hi newbee here. I just installed FreeBSD on my x1 carbon 6th gen. Everything is fine, except that I found acpi_ibm is broken. It does not behave like what manual says, no sysctl keys, no /dev/led.
Do others using recent ThinkPads have the same problem? I found a pending patch here https://reviews.freebsd.org/D14103 but have no idea how to install it. I'm also confused because the freebsd laptop wiki never mentions it and I don't know if this is just because of my misconfiguration.
Any hints are appreciated!
 
There a related PR 229120 which was merged into CURRENT and which was discussed on Thread thinkpad-x1-multimedia-keys.69476.

If you do not want to run CURRENT, or want to try the Phabricator patch, you'll have to patch the kernel source.

There's a "Download Raw Diff" link on the page that you linked to (and a similar link on the PR's page). When you download the diff file, you have to use patch(1) to apply it to the kernel source that you've checked out, and then compile and install the patched kernel (see this link for instructions on how to check out FreeBSD source and compile the kernel). If the version of the kernel that you've checked out is close to the version that you are running on your system, you might get away with compiling and installing just the acpi_ibm(4) module.

Regards,
Bojan
 
There a related PR 229120 which was merged into CURRENT and which was discussed on Thread thinkpad-x1-multimedia-keys.69476.

If you do not want to run CURRENT, or want to try the Phabricator patch, you'll have to patch the kernel source.

There's a "Download Raw Diff" link on the page that you linked to (and a similar link on the PR's page). When you download the diff file, you have to use patch(1) to apply it to the kernel source that you've checked out, and then compile and install the patched kernel (see this link for instructions on how to check out FreeBSD source and compile the kernel). If the version of the kernel that you've checked out is close to the version that you are running on your system, you might get away with compiling and installing just the acpi_ibm(4) module.

Regards,
Bojan
PR 229120 compiles but still gives no sysctl varaibles, the other just doesn't compile. I tried both on 12-release and do kldload, and I then checkout 12-stable and buildworld, with no success...
 
There a related PR 229120 which was merged into CURRENT and which was discussed on Thread thinkpad-x1-multimedia-keys.69476.

If you do not want to run CURRENT, or want to try the Phabricator patch, you'll have to patch the kernel source.

There's a "Download Raw Diff" link on the page that you linked to (and a similar link on the PR's page). When you download the diff file, you have to use patch(1) to apply it to the kernel source that you've checked out, and then compile and install the patched kernel (see this link for instructions on how to check out FreeBSD source and compile the kernel). If the version of the kernel that you've checked out is close to the version that you are running on your system, you might get away with compiling and installing just the acpi_ibm(4) module.

Regards,
Bojan
PR 229120 compiles but still gives no sysctl varaibles, the other just doesn't compile. I tried both on 12-release and do kldload, and I then checkout 12-stable and buildworld, with no suc
There a related PR 229120 which was merged into CURRENT and which was discussed on Thread thinkpad-x1-multimedia-keys.69476.

If you do not want to run CURRENT, or want to try the Phabricator patch, you'll have to patch the kernel source.

There's a "Download Raw Diff" link on the page that you linked to (and a similar link on the PR's page). When you download the diff file, you have to use patch(1) to apply it to the kernel source that you've checked out, and then compile and install the patched kernel (see this link for instructions on how to check out FreeBSD source and compile the kernel). If the version of the kernel that you've checked out is close to the version that you are running on your system, you might get away with compiling and installing just the acpi_ibm(4) module.

Regards,
Bojan
Tell me if I'm doing something unmeaningful. I'm trying to debug acpi_ibm.c myself. I just start by adding a device_printf(dev,"say stuff\n") at the beginning of acpi_ibm_probe and acpi_ibm_attach, make install, then kldunload kldload... then I check dmesg, there were nothing! So the ko is not even loaded?
 
If you do make; make install inside /usr/src/sys/modules/acpi/acpi_ibm, you should see something like:

Code:
install -T release -o root -g wheel -m 555   acpi_ibm.ko /boot/modules/

This means that the module is being installed into /boot/modules, which is shadowed by the /boot/kernel directory, as you can see in the output of sysctl kern.module_path. You will have to load the patched module through its absolute path: kldload /boot/modules/acpi_ibm.ko, otherwise, the old module inside /boot/kernel will be loaded.

I hope this helps.
 
If you do make; make install inside /usr/src/sys/modules/acpi/acpi_ibm, you should see something like:

Code:
install -T release -o root -g wheel -m 555   acpi_ibm.ko /boot/modules/

This means that the module is being installed into /boot/modules, which is shadowed by the /boot/kernel directory, as you can see in the output of sysctl kern.module_path. You will have to load the patched module through its absolute path: kldload /boot/modules/acpi_ibm.ko, otherwise, the old module inside /boot/kernel will be loaded.

I hope this helps.
Thanks a lot! It works now, I can even see lots of "say stuff" on my console.
 
If you do make; make install inside /usr/src/sys/modules/acpi/acpi_ibm, you should see something like:

Code:
install -T release -o root -g wheel -m 555   acpi_ibm.ko /boot/modules/

This means that the module is being installed into /boot/modules, which is shadowed by the /boot/kernel directory, as you can see in the output of sysctl kern.module_path. You will have to load the patched module through its absolute path: kldload /boot/modules/acpi_ibm.ko, otherwise, the old module inside /boot/kernel will be loaded.

I hope this helps.
I managed to merge D14103 by hand (just patch it won't compile) and it turns out that it is doing much more things than the PR (which mostly just changes some IDs). The keyboard backlight works.
The overlap is something causing conflict to D14103, the method IDs conflict, but D14103 is indeed doing additional things. Now I have functionalities from both running ;)
 
Back
Top