The Final Zone project

Following previous topic , testing the build kernel 4.8.0rc4 with the patch related to ACPI EC allow unlocking the functionality of hotkeys. For the first time, ASUS X550ZE has nearly full functionality from keyboard in Linux operating system (Fedora in my case) on par with Microsoft Windows 8.1 and 10.  Hopefully other laptops having similar problem will regain that access. For that learned experience, that bug turned out more complex than expected revealing a different ACPI scheme used in Microsoft Windows 10 and a bad practice from BIOS vendor. It also shows how some vendors ignore standard procedure thus making harder to find the problem. The important lesson is the cooperation between users and developers exchanging knowledge and discovering new elements never seen before. One day, vendors will open themselves approaching the kernel community to improve their products. Now the hotkeys saga comes to the end, the next step is the support of AMD hybrid graphic card. This blo

Resuming for the previous topic , with the help of an Arch user and one of kernel maintainers, it turned out the failure of hotkeys functions [Fn] is due to a Linux ACPI bug. Further investigation revealed a bad practice from BIOS vendor and unexpectedly a new challenge in Linux kernel world as quoted: However this report indicates us another gap (except the enumeration order gap): If the namespace EC (DSDT EC in short) is not ready, EC access availability can be kept using the ECDT EC. In Linux, that requres _Qxx control methods to be registered for the ECDT EC. I have never seen a Linux EC driver version doing this before, _Qxx registration is only invoked in acpi_ec_add(). So this bug indicates a gap for Linux. Essentially, what is initially a bug related for non-functional hotkeys for ASUS X550Z laptop revealed a much more deeper issue related Linux ACPI. It is the first time I reached that level of testing in kernel world with the help from upstream kernel. A built kernel