milesp20/intel_nuc_led

Intel NUC7i[x]BN and NUC6CAY LED Control for Linux

Intel NUC7i[x]BN and NUC6CAY LED Control

This is a simple kernel module to control the power and ring LEDs on Intel NUC7i[x]BN and NUC6CAY kits.

This module is intended as a demonstration/proof-of-concept and may not be maintained further. Perhaps it can act as a jumping off point for a more polished and complete implementation. For testing and basic manipulation of the power LED and ring LED, it ought to work fine, but use with caution none the less. This has only been tested on 4.4.x kernels.

Requirements

Requirements:

• Intel NUC7i[x]BN and NUC6CAY
• BIOS AY0038 or BN0043 or later
• ACPI/WMI support in kernel
• LED(s) set to SW Control in BIOS

Building

THe nuc_led kernel module supports building and installing "from source" directly or using dkms.

Installing Build Dependencies

Ubuntu:

apt-get install build-essential linux-headers-$(uname -r)

# DKMS dependencies
apt-get install debhelper dkms

Redhat:

yum groupinstall "Development Tools"
yum install kernel-devel-$(uname -r)

# Install appropriate EPEL for DKMS if needed by your RHEL variant
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

yum install dkms

Building and Installing "from source"

make clean
make install

Building and Installing Using DKMS

Build and install without system packaging:

make dkms-install

Uninstall without system packaging:

make dkms-uninstall

Build and install using system packaging:

# Ubuntu
make dkms-deb

# RHEL
make dkms-rpm

# Install generated DEB/RPM from the folder specified in the output using system package manager

Usage

This driver works via '/proc/acpi/nuc_led'. To get current LED state:

cat /proc/acpi/nuc_led

To change the LED state:

 echo '<led>,<brightness>,<blink/fade>,<color>' | sudo tee /proc/acpi/nuc_led > /dev/null

LED	Description
power	The power button LED.
ring	The ring LED surrounding the front panel.

Brightness:

• any integer between 0 and 100.

Blink/Fade Option	Description
blink_fast	1Hz blink
blink_medium	0.5Hz blink
blink_slow	0.25Hz blink
fade_fast	1Hz blink
fade_medium	0.5Hz blink
fade_slow	0.25Hz blink
none	solid/always on

LED Color	power	ring
amber	X
cyan		X
blue	X	X
green		X
off	X	X
pink		X
red		X
white		X
yellow		X

Example execution to cause the ring LED blink green at a medium rate at partial intensity:

echo 'ring,80,blink_medium,green' | sudo tee /proc/acpi/nuc_led > /dev/null

Errors in passing parameters will appear as warnings in dmesg.

You can change the owner, group and permissions of /proc/acpi/nuc_led by passing parameters to the nuc_led kernel module. Use:

• nuc_led_uid to set the owner (default is 0, root)
• nuc_led_gid to set the owning group (default is 0, root)
• nuc_led_perms to set the file permissions (default is r+w for group and user and r for others)

Note: Once an LED has been set to SW Control in the BIOS, it will remain off initially until a color is explicitly set, after which the set color is retained across reboots.

intel_nuc_led's Issues

NUC8i7HVK support

Can this be extended to support the Hades Canyon (NUC8i7HVK) NUC ?

It has a few LEDs but mainly the skull LEDs to control, https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/nuc-kits/LED-Manager-User-Guide.pdf

Would be nice to make colors change when connected to VPN for example.

Add support for NUC8i7HVK

The new Hades Canyon NUC systems have a number of controllable LEDs. It would be cool to extend the functionality of this software to support those LEDs as well.

Fade settings not working

Attempting to set to fade_slow or fade_medium fails with a "Unable to set NUC LED state: invalid parameter" error. Example:

echo 'ring,100,fade_slow,red' > /proc/acpi/nuc_led

/proc/acpi/nuc_led output is null character terminated (potential buffer overflow)

This IMO is a subtle bug which may be an off by one error somewhere in the generated output string buffer index.

In general if you use Bash to capture the output of the /proc/acpi/nuc_led to later process it like this:

nuc_led_output="$(cat /proc/acpi/nuc_led)"

Then you get a warning along the lines of:

Bash: warning: command substitution: ignored null byte in input

This is because you are adding the null byte ('\0') into the middle of the Bash string which internally is also a C string, so it ignores it.

This leads me to believe that the function that is creating the string buffer is either printing one character past the end of the actual buffer and overflowing it (causing the null character to be printed) or its being purposely injected/included in the output string. It would be better for the null byte not to be included in the output.

As a workaround, I have just been translating away the null byte:

nuc_led_output="$(cat /proc/acpi/nuc_led | tr "\0" "\n")"

Writing behind the allocated memory

Code excerpt:

input = vmalloc(len);
...
input[len] = '\0';

From

intel_nuc_led/nuc_led.c

Line 234 in 6a3850e

input = vmalloc(len);

That should be:

input = vmalloc(len+1);
...
input[len] = '\0';

Having trouble with /proc/acpi/nuc_led creation

Not sure if this is a issue so much as i might just be doing something stupid.

Running Ubuntu 16.04, Linux 4.15.0-24-generic kernal on a Nuc NUC7i7BNB, BIOS Version: BNKBL357.86A.0065.2018.0606.1639 (aka version 65, the latest). LEDs are set to SW control in BIOS.

I go through the install steps via deb. it makes the deb file fine, i install it fine. But there's no /proc/acpi/nuc_led file. Not sure if there's a unspoken step here I'm missing.

I also tried making and installing it in various other ways but I'm super clueless here so any help would be appreciated.

Support for NUC7i[x]DNBE?

Hello,
I have an NUC7i7DNBE board which has a power LED with a SW mode option in the BIOS.
As its the same power LED setup I was hoping it would work, although sadly when I query the nuc_led I get:

cat /proc/acpi/nuc_led
Power LED not set for software control

Ring LED not set for software control

Module fails on Kernel 4.15

Module was working perfectly on Mint 18.3 with kernel 4.10. Recently upgraded to Mint 19.1 and kernel 4.15, and module is broken. "cat /proc/acpi/nuc_led" gives a kernel log error of "Unable to get NUC power LED state" followed by a similar message for the ring. Attempting to set the state gives a kernel log error of "Unable to set NUC LED state: WMI call failed."

Could we get a version for the NUC8i3 and NUC8i5?

I'd like to see this for the NUC8i3 and I'm sure some others would like to see a version for the NUC8i5.

DKMS install failing on Debain 11, kernel 5.10.x

Hardware: NUC6CAYH
OS: Debain Bullseye - Kernel 5.10.0-9-amd64

Problem: When I attempt the dkms-install, I'm getting errors back.

$ sudo make dkms-install
dkms add --force /home/noah/intel_nuc_led

Creating symlink /var/lib/dkms/intel-nuc-led/1.0/source ->
                 /usr/src/intel-nuc-led-1.0

DKMS: add completed.
dkms build -m intel-nuc-led -v 1.0

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j4 KERNELRELEASE=5.10.0-9-amd64 -C /lib/modules/5.10.0-9-amd64/build M=/var/lib/dkms/intel-nuc-led/1.0/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.10.0-9-amd64 (x86_64)
Consult /var/lib/dkms/intel-nuc-led/1.0/build/make.log for more information.
make: *** [Makefile:19: dkms-build] Error 10

The contents of that log file:

DKMS make.log for intel-nuc-led-1.0 for kernel 5.10.0-9-amd64 (x86_64)
Mon 13 Dec 2021 12:18:55 PM EST
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-9-amd64'
  CC [M]  /var/lib/dkms/intel-nuc-led/1.0/build/nuc_led.o
/var/lib/dkms/intel-nuc-led/1.0/build/nuc_led.c: In function ‘init_nuc_led’:
/var/lib/dkms/intel-nuc-led/1.0/build/nuc_led.c:475:75: error: passing argument 4 of ‘proc_create’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  475 |         acpi_entry = proc_create("nuc_led", nuc_led_perms, acpi_root_dir, &proc_acpi_operations);
      |                                                                           ^~~~~~~~~~~~~~~~~~~~~
      |                                                                           |
      |                                                                           struct file_operations *
In file included from /var/lib/dkms/intel-nuc-led/1.0/build/nuc_led.c:36:
/usr/src/linux-headers-5.10.0-9-common/include/linux/proc_fs.h:109:122: note: expected ‘const struct proc_ops *’ but argument is of type ‘struct file_operations *’
  109 | struct proc_dir_entry *proc_create(const char *name, umode_t mode, struct proc_dir_entry *parent, const struct proc_ops *proc_ops);
      |                                                                                                   ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
cc1: some warnings being treated as errors
make[3]: *** [/usr/src/linux-headers-5.10.0-9-common/scripts/Makefile.build:285: /var/lib/dkms/intel-nuc-led/1.0/build/nuc_led.o] Error 1
make[2]: *** [/usr/src/linux-headers-5.10.0-9-common/Makefile:1846: /var/lib/dkms/intel-nuc-led/1.0/build] Error 2
make[1]: *** [/usr/src/linux-headers-5.10.0-9-common/Makefile:185: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-9-amd64'

Thanks all!!

memory leak on nuc?

In using the driver (thanks for doing that!), I noticed that if i continuously write to the LED, memory is leaking. Has something to do with vmalloc()/vfree(). If I have the write function immediately return, no memory leak is detected. I then did only vmalloc()/vfree() & then return - memory started leaking. I switched to kmalloc() and kfree() & the issue appears to be gone.

Not sure why vmalloc() is being used, as kmalloc() seems more appropriate. vmalloc() should work, admittedly. I'm not a linux-driver person at all, so I may be offbase.

This is on an Intel NUC6CAYH running Ubuntu 16.04, BIOS version AY00047.

On Debian 9.5 the module is not built in local directory

I installed this kernel module in some systems on debian 9.5. The instructions suggest that the nuc_led.ko file will be in the local directory where insmod can find it. That may be true for other systems, but it is not true for me. Instead, it was in the dkms tree at:

/var/lib/dkms/intel-nuc-led/1.0/4.9.0-7-amd64/x86_64/module/nuc_led.ko

I will submit a pull request to update the README, but I'm guessing there's more to the instructions that need to be updated than this.

NUC8i7BEH?

Hello,
I tried it with an NUC8i7BEH (firmware is up to date, version BECFL357.86A.0056.2018.1128.1717). Compilation and module insertion were successful (although with some warnings), however usage was not:

make_default.log

root@nuc:# uname -r
4.19.0-1-amd64
root@nuc:# insmod user/devel/github.com/milesp20/intel_nuc_led/nuc_led.ko
root@nuc:# cat /proc/acpi/nuc_led
Power LED state could not be determined: WMI call returned error

Ring LED state could not be determined: WMI call returned error

root@nuc:# rmmod nuc_led
root@nuc:# dmesg | tail
[...]
[ 1890.836840] nuc_led: Intel NUC LED control driver loaded
[ 1898.035911] nuc_led: Intel NUC LED control driver unloaded

Do you have any idea what the problem might be?

Thank you in advance and best regards

ACPI BIOS ERROR: Buffer Limit?

I have a NUC11 Beast Canyon (the mini PC form factor w/the skull on front) and trying to get the LEDs going in Ubuntu 20.04. I've tried this project as well as many of the various forks and keep running into this:

[ 4352.076055] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [CMD4] at bit offset/length 32/8 exceeds size of target Buffer (32 bits) (20201113/dsopcode-198)

[ 4352.076063] No Local Variables are initialized for Method [WMAA]

[ 4352.076065] Initialized Arguments for Method [WMAA]:  (3 arguments defined for method invocation)
[ 4352.076065]   Arg0:   00000000d9602656 <Obj>           Integer 0000000000000000
[ 4352.076070]   Arg1:   000000004c70c5eb <Obj>           Integer 0000000000000005
[ 4352.076073]   Arg2:   00000000078799a2 <Obj>           Buffer(4) 05 03 00 00

[ 4352.076080] ACPI Error: Aborting method \AMW0.WMAA due to previous error (AE_AML_BUFFER_LIMIT) (20201113/psparse-529)
[ 4352.076088] ACPI Error: AE_AML_BUFFER_LIMIT, wmi_evaluate_method (20201113/NUC_LED-267)

The correct GUID is there it just seems like it doesn't "take" the commands and I can't find any further information beyond this error message (output from dmesg after attempting to write to the kernel device). There are no LED settings in the BIOS besides the power button LED, and it has the latest BIOS. Presumably it works in Windows w/the Intel tool so I would assume the correct WMI things are in place to allow it to work. Any thoughts appreciated.

Error making - code model kernel does not support PIC mode

When attempting to make the module I get:

make -C /lib/modules/4.15.0-20-generic/build M=/home/bill/Projects/intel_nuc_led modules
make[1]: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
  CC [M]  /home/bill/Projects/intel_nuc_led/nuc_led.o
cc1: error: code model kernel does not support PIC mode
scripts/Makefile.build:339: recipe for target '/home/bill/Projects/intel_nuc_led/nuc_led.o' failed
make[2]: *** [/home/bill/Projects/intel_nuc_led/nuc_led.o] Error 1
Makefile:1552: recipe for target '_module_/home/bill/Projects/intel_nuc_led' failed
make[1]: *** [_module_/home/bill/Projects/intel_nuc_led] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
Makefile:8: recipe for target 'default' failed
make: *** [default] Error 2

This is a new install on a NUC7i5BNH with Ubuntu Server 18.04.

╰─➤  uname -a
Linux hyrule 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

not working on NUC7i5BNH

Hi,
not sure on the difference with this model as opposed to other NUC7i5BN series NUC's but I have been unable to make this work.
I have set both of the BIOS settings to 'software control' for the leds and I have checked that the GUID and it exists once I install the WMI module

As I not a kernel program by any stretch I was wondering if you could make a version with a higher debug as all I get is the following when I cat the nuc_led file in proc
Power LED state could not be determined: WMI call failed

Ring LED state could not be determined: WMI call failed

Thanks
Jason