NUC8i7BEH?

[TomPortman]

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

[dessatel]

I have the same issue with bean canyon nucs. Posted question on Intel NUC forums. Hades WMI commands are not supported either.

Doing some test on NUC8i7BE with the latest BIOS ( the same happens on NUC8i3x) Commands 0x1/0x2 - returns 0xE1-function not supported, return ACPI buffer type length 152 bytes All other command (0,3,4,5,6) - return ACPI 'integer' (0) S/W control is enabled in BIOS settings ( and RGB LEDs are not lit when s/w control is enabled) It is almost like either BIOS or firmware is not supporting new LED WMI properly (Revision 0.64) and disabled old LED WMI ?

System Details:

Ubuntu : Linux chroma64-studio 4.15.0-20-lowlatency #21-Ubuntu SMP PREEMPT Tue Apr 24 07:52:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux BIOS Version 0064 - BECFL357.86A.0064.2019.0213.1122

fwts wmi - seems correct: \AMW0._WDG (1 of 2) GUID: 8C5DA44C-CDC3-46B3-8619-4E26D34390B7 WMI Method: Flags : 0x02 (Method) Object ID : AA Instance : 0x01 PASSED: Test 1, 8C5DA44C-CDC3-46B3-8619-4E26D34390B7 has associated method \AMW0.WMAA

\AMW0._WDG (2 of 2) GUID: 05901221-D566-11D1-B2F0-00A0C9062910 WMI Object: Flags : 0x00 (None) Object ID : BA Instance : 0x01

60965 Method (WMAA, 3, NotSerialized) 60966 { 60967 CLSB (INFO) 60968 CreateDWordField (INFO, Zero, BUF0) 60969 BUF0 = 0x44534943 60970 If ((Arg1 == One)) 60971 { 60972 _SB.GLED (Arg2, INFO) 60973 If ((BUF0 == 0x44534943)) 60974 { 60975 CLSB (INFO) 60976 INF0 = 0xE2 60977 } 60978 60979 Local1 = INFO /* \AMW0.INFO */ 60980 Return (Local1) 60981 }

60982 60983 If ((Arg1 == 0x02)) 60984 { 60985 _SB.SLED (Arg2, INFO) 60986 If ((BUF0 == 0x44534943)) 60987 { 60988 CLSB (INFO) 60989 INF0 = 0xE2 60990 } 60991 60992 Local1 = INFO /* \AMW0.INFO */ 60993 Return (Local1) 60994 } 60995 } 60996 }

[screeny05]

Would be interested in a working version for the NUC8i7BEH as well.

[jernst]

This guy here seems to say that is was shipped broken: https://github.com/GothAck/nuc8_beh_led_linux If so, the mind boggles. Nobody even bothered to update the docs which say that the LED is software controllable, and the BIOS that has a setting for it, too.

And I'm just noticing that the release notes for the latest BIOS update say "Remove the option “SW Control” on “RGB LED” and “Button LED” items." -- but perhaps the phrase "... because it never worked" is missing? https://downloadmirror.intel.com/28951/eng/BE_0073_ReleaseNotes.pdf

[jernst]

Talked to Intel support. If you can parse the statement, I think it says "yes, it doesn't work, and please ignore that our documentation implies otherwise":

This is xxx from Intel technical Department.

In this case, the NUC department has confirmed that the only way the customer can change or modify RGB LED would be through the BIOS under power options, the NUC does not a software control through windows, however, we will be submitting a voice of the customer survey, in order your feedback get’s heard.

[jernst]

I have updated the kernel module for NUC10. Would love to hear whether it can work for other NUC models as well. https://github.com/uboslinux/intel-nuc-led/