Micmute led on Matebook D #7

wasakakero · 2019-04-15T11:32:43Z

Hi,

all keys worked perfectly fine when installing Fedora on my Matebook D, I only had to update the hwdb tables directly for the micmute button to work.

However, it is impossible to turn off the Micmute led, it has been this way since installation probably as a remnant of when I had windows.

Is there any fix for this in the works? is there any way I can help by sending logs or something?

aymanbagabas · 2019-04-15T12:51:23Z

Hey, thanks for reporting this issue.

Is there any fix for this in the works? is there any way I can help by sending logs or something?

Not right now. It would be very helpful if you provide me the DSDT/SSDT tables for your model and the year for your model.

wasakakero · 2019-04-15T12:59:19Z

I can certainly do so, would you point me out to how I can provide the DSDT/SSDT tables?

Thanks!

aymanbagabas · 2019-04-15T13:02:48Z

I can certainly do so, would you point me out to how I can provide the DSDT/SSDT tables?

Please take a look at acpidump. I only need DSDT.dat and SSDT*.dat

wasakakero · 2019-04-15T13:30:49Z

Hopefully this works?

https://github.com/wasakakero/matebook-d-ryzen-dsdt-ssdt

aymanbagabas · 2019-04-15T13:44:37Z

Hopefully this works?

Yeah this works. Thanks!

aymanbagabas · 2019-04-15T16:58:04Z

Using a tool like acpi_call could you provide the return values and observe any changes to your system using the following?

$ echo "\SMLS 0" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call
$ echo "\SMLS 0x00010000" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call

wasakakero · 2019-04-15T18:33:31Z

I'll be honest, I've spent the last hour trying to figure out how to install this, I've tried different stuff and "call" never appears on /proc/acpi

Any suggestions?

Edit: Managed to install it somehow, found a forum thread of someone on Solus having the same issues I had, I did not notice anything changing when entering the above commands.

[wasakakero@localhost acpi_call] $ sudo modprobe acpi_call

[wasakakero@localhost acpi_call] $ echo "\SMLS 0" | sudo tee /proc/acpi/call
\SMLS 0

[wasakakero@localhost acpi_call] $ sudo cat /proc/acpi/call
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

[wasakakero@localhost acpi_call] $ echo "\SMLS 0x00010000" | sudo tee /proc/acpi/call
\SMLS 0x00010000

[wasakakero@localhost acpi_call] $ sudo cat /proc/acpi/call
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

[wasakakero@localhost acpi_call] $

Edit 2: I've tried something else, and now after entering the first command, the led is turned off, echo "\SMLS 0x00010000" | sudo tee /proc/acpi/call turns it back on.

aymanbagabas · 2019-04-17T23:11:03Z

@wasakakero could I get the output of this

$ sudo dmidecode -t1

I'm trying to get the product name defined in dmi. I'm working on a driver update that brings on a fix for this issue along with other issues.

wasakakero · 2019-04-18T11:47:57Z

@aymanbagabas sure thing, here it is:

[wasakakero@localhost ~] $ sudo dmidecode -t1
[sudo] password for wasakakero: 
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.10.1 present.
# SMBIOS implementations newer than version 3.2.0 are not
# fully supported by this version of dmidecode.

Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: HUAWEI
        Product Name: KPL-W0X
        Version: M1D
        Serial Number: ADTPM18A09000218
        UUID: c94bbb84-f826-4310-b653-b8ebe4900a9a
        Wake-up Type: Power Switch
        SKU Number: C100
        Family: MateBook D

[wasakakero@localhost ~] $

aymanbagabas · 2019-04-22T23:14:49Z

@wasakakero can you please try the updated module from master?
commit

wasakakero · 2019-04-22T23:33:14Z

@aymanbagabas I tried to install as per the readme and I got the following error during "make"

[wasakakero@localhost Huawei-WMI]$ make
make -C /lib/modules/5.0.7-200.fc29.x86_64/build/ M=/home/wasakakero/Huawei-WMI modules
make[1]: *** /lib/modules/5.0.7-200.fc29.x86_64/build/: No such file or directory.  Stop.
make: *** [Makefile:8: modules] Error 2
[wasakakero@localhost Huawei-WMI]$

aymanbagabas · 2019-04-22T23:35:30Z

@aymanbagabas I tried to install as per the readme and I got the following error during "make"

[wasakakero@localhost Huawei-WMI]$ make
make -C /lib/modules/5.0.7-200.fc29.x86_64/build/ M=/home/wasakakero/Huawei-WMI modules
make[1]: *** /lib/modules/5.0.7-200.fc29.x86_64/build/: No such file or directory.  Stop.
make: *** [Makefile:8: modules] Error 2
[wasakakero@localhost Huawei-WMI]$

Seems like you're using Fedora, right? Make sure you have kernel-devel and kernel-modules packages. I will add that to the readme.

wasakakero · 2019-04-22T23:59:08Z

@aymanbagabas I now encounter this issue:

[wasakakero@localhost Huawei-WMI]$ sudo make install
[sudo] password for wasakakero: 
make -C /lib/modules/5.0.7-200.fc29.x86_64/build/ M=/home/wasakakero/Huawei-WMI modules_install
make[1]: Entering directory '/usr/src/kernels/5.0.7-200.fc29.x86_64'
  INSTALL /home/wasakakero/Huawei-WMI/huawei-wmi.ko
At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: crypto/bio/bss_file.c:72
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: crypto/bio/bss_file.c:79
sign-file: certs/signing_key.pem: No such file or directory
  DEPMOD  5.0.7-200.fc29.x86_64
make[1]: Leaving directory '/usr/src/kernels/5.0.7-200.fc29.x86_64'
depmod -a
[wasakakero@localhost Huawei-WMI]$

I don't know if it was installed or not, but after a reboot, I noticed that the micmute key no longer works even after updating the hwdb tables, but please bear in mind this last part might be unrelated as I re-installed Fedora a few days ago and I never updated the tables up until the restart I mentioned.

aymanbagabas · 2019-04-23T00:06:39Z

I don't know if it was installed or not, but after a reboot, I noticed that the micmute key no longer works even after updating the hwdb tables, but please bear in mind this last part might be unrelated as I re-installed Fedora a few days ago and I never updated the tables up until the restart I mentioned.

Looks like it was built just fine. Don't forget to unload the driver before you make install.

$ sudo rmmod huawei_wmi
$ make
$ sudo insmod huawei-wmi.c

Remember, this is still in testing so you probably don't want to install it in your system.

Also try make clean before you attempt to build. Once you have your hwdb tables you have to reboot for it to take effect.

wasakakero · 2019-04-23T00:56:08Z

@aymanbagabas I did as instructed, but it seems to have no effect, micmute still doesn't work after rebooting (I'm puzzled as to why) and insmod throws me:

[wasakakero@localhost Huawei-WMI]$ sudo insmod huawei-wmi.c
insmod: ERROR: could not insert module huawei-wmi.c: Invalid module format
[wasakakero@localhost Huawei-WMI]$

aymanbagabas · 2019-04-23T01:04:06Z

@aymanbagabas I did as instructed, but it seems to have no effect, micmute still doesn't work after rebooting (I'm puzzled as to why) and insmod throws me:
[wasakakero@localhost Huawei-WMI]$ sudo insmod huawei-wmi.c
insmod: ERROR: could not insert module huawei-wmi.c: Invalid module format
[wasakakero@localhost Huawei-WMI]$ 

Sorry my bad, that should've been sudo insmod huawei-wmi.ko .ko. Please try this

$ cd /tmp
$ git clone https://github.com/aymanbagabas/Huawei-WMI
$ cd Huawei-WMI
$ make clean
$ make
$ sudo rmmod huawei_wmi
$ sudo insmod huawei-wmi.ko

Could you please also provide your dmesg output.

wasakakero · 2019-04-23T01:12:02Z

@aymanbagabas the hwdb thing not working was my fault, I was stupid and figured it out myself.

As for the module, it seems that worked, i didn't get any feedback from the console with the last 2 commands if that means it was succesful.

I tried before and after rebooting and the led never turned on (or off).

please find attached the dmesg, the last lines I guess are me pressing micmute soon after entering into the DE, which is weird because the key does work.

dmesg.txt

aymanbagabas · 2019-04-23T01:22:08Z

please find attached the dmesg, the last lines I guess are me pressing micmute soon after entering into the DE, which is weird because the key does work.

dmesg.txt

Thank you for taking the time in this. As for the last line, I had the same with my MBXP. With my model, any time I press brightness keys, micmute, wifi, or huawei mgmt key I get scan code f7. I simply remapped that to unknown as you can see in the 99-Huawei.hwdb. I believe this the same case.

If you want, create a pr with this fix either here in this repo or directly to systemd project.

Could you please test the newly added features? battery protection and fn-lock? Please report to #8 if you're interested. Thank you!

wasakakero · 2019-04-23T01:33:46Z

@aymanbagabas just to be clear the LED didn't work.

As for #8 I can certainly try them out, but I have no idea how I would go on setting up the battery protection settings since there is no PC Manager, I'm not aware of a key combination for this.

And I have to ask, since I rebooted after inserting the module, is it still in there or I have to do the commands all over and test without rebooting?

Edit: I'll also attach the output of make, just in case.
make.txt

aymanbagabas · 2019-04-23T02:01:36Z

@aymanbagabas just to be clear the LED didn't work.

Hmm.. could you please try this and provide dmesg output. Make sure you're using the driver from this repo. If you haven't installed the driver using make install, make sure you unload the old driver that's equipped with the kernel and load this one after compile.
huawei-wmi.zip

Also try these using acpi_call and give me the output

$ echo "\SMLS 0x00010000" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call
$ echo "\SMLS 0x00000000" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call
$ echo "\_SB.WMI1.WMAA 0 0 0x00000b04" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call
$ echo "\_SB.WMI1.WMAA 0 0 0x00010b04" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call

aymanbagabas · 2019-04-23T02:08:30Z

As for #8 I can certainly try them out, but I have no idea how I would go on setting up the battery protection settings since there is no PC Manager, I'm not aware of a key combination for this.

And I have to ask, since I rebooted after inserting the module, is it still in there or I have to do the commands all over and test without rebooting?

There is no key combination for this. In Windows and using Huawei PC Manager, you can set battery charging thresholds/limits so it protects your battery from wearing down quickly.

You can also change the behavior of the Fn key as if it was the opposite. So the default behavior while fn toggled off (led off) pressing F1-F12 would trigger a hotkey. If this fn-lock thing is on, it would trigger the F1-F12 key instead of a hotkey so it would be the opposite as if you're holding Fn.

wasakakero · 2019-04-23T13:54:26Z

Also try these using acpi_call and give me the output

$ echo "\SMLS 0x00010000" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call
$ echo "\SMLS 0x00000000" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call
$ echo "\_SB.WMI1.WMAA 0 0 0x00000b04" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call
$ echo "\_SB.WMI1.WMAA 0 0 0x00010b04" | sudo tee /proc/acpi/call
$ sudo cat /proc/acpi/call

I did as instructed and here are the results:

Micmute LED turned on:

[wasakakero@localhost Huawei-WMI]$ echo "\SMLS 0x00010000" | sudo tee /proc/acpi/call
\SMLS 0x00010000
[wasakakero@localhost Huawei-WMI]$ sudo cat /proc/acpi/call
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

Micmute LED turned off:

[wasakakero@localhost Huawei-WMI]$ echo "\SMLS 0x00000000" | sudo tee /proc/acpi/call
\SMLS 0x00000000
[wasakakero@localhost Huawei-WMI]$ sudo cat /proc/acpi/call
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

Didnt notice any change:


[wasakakero@localhost Huawei-WMI]$ echo "\_SB.WMI1.WMAA 0 0 0x00000b04" | sudo tee /proc/acpi/call
\_SB.WMI1.WMAA 0 0 0x00000b04
[wasakakero@localhost Huawei-WMI]$ sudo cat /proc/acpi/call
[{0x00, 0x00, 0x00, 0x00}, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

Didn't notice any change:


[wasakakero@localhost Huawei-WMI]$ echo "\_SB.WMI1.WMAA 0 0 0x00010b04" | sudo tee /proc/acpi/call
\_SB.WMI1.WMAA 0 0 0x00010b04
[wasakakero@localhost Huawei-WMI]$ sudo cat /proc/acpi/call
[{0x00, 0x00, 0x00, 0x00}, {0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

wasakakero · 2019-04-23T14:00:06Z

As for #8 I can certainly try them out, but I have no idea how I would go on setting up the battery protection settings since there is no PC Manager, I'm not aware of a key combination for this.
And I have to ask, since I rebooted after inserting the module, is it still in there or I have to do the commands all over and test without rebooting?

There is no key combination for this. In Windows and using Huawei PC Manager, you can set battery charging thresholds/limits so it protects your battery from wearing down quickly.

You can also change the behavior of the Fn key as if it was the opposite. So the default behavior while fn toggled off (led off) pressing F1-F12 would trigger a hotkey. If this fn-lock thing is on, it would trigger the F1-F12 key instead of a hotkey so it would be the opposite as if you're holding Fn.

Are the instructions referred in #9 valid for the battery protection in this device as well?

I can confirm that the FN Key work as intended in both v1 and v2 as far as I know, led on means F1-F12 keys act as F1-F12 keys, led off means they act as the hotkeys for birghtness, volume, wifi and so on.

aymanbagabas · 2019-04-23T14:11:18Z

[wasakakero@localhost Huawei-WMI]$ echo "_SB.WMI1.WMAA 0 0 0x00010b04" | sudo tee /proc/acpi/call
_SB.WMI1.WMAA 0 0 0x00010b04
[wasakakero@localhost Huawei-WMI]$ sudo cat /proc/acpi/call
[{0x00, 0x00, 0x00, 0x00}, {0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

Thank you for keeping up with this. I just noticed in SSDT1 of your model that every call to WMAA checks a local variable if it's set to 2, it passes the command, otherwise, it doesn't and returns 1 meaning incorrect input or something. I haven't seen this in other models and I don't see the point of having this in the AML code. That's why you get '0x01' in your output. Please try running that command twice and see if it turns the led on.

aymanbagabas · 2019-04-23T14:13:55Z

I can confirm that the FN Key work as intended in both v1 and v2 as far as I know, led on means F1-F12 keys act as F1-F12 keys, led off means they act as the hotkeys for birghtness, volume, wifi and so on.

This mode inverts this behavior so led on and F1-F12 give hotkeys.

wasakakero · 2019-04-23T14:40:24Z

@aymanbagabas I tried running the command twice, didn't see the led turning on.

[wasakakero@localhost Huawei-WMI]$ echo "\_SB.WMI1.WMAA 0 0 0x00000b04" | sudo tee /proc/acpi/call
\_SB.WMI1.WMAA 0 0 0x00000b04
[wasakakero@localhost Huawei-WMI]$ echo "\_SB.WMI1.WMAA 0 0 0x00000b04" | sudo tee /proc/acpi/call
\_SB.WMI1.WMAA 0 0 0x00000b04

aymanbagabas · 2019-04-23T15:20:13Z

@aymanbagabas I tried running the command twice, didn't see the led turning on.

[wasakakero@localhost Huawei-WMI]$ echo "\_SB.WMI1.WMAA 0 0 0x00000b04" | sudo tee /proc/acpi/call
\_SB.WMI1.WMAA 0 0 0x00000b04
[wasakakero@localhost Huawei-WMI]$ echo "\_SB.WMI1.WMAA 0 0 0x00000b04" | sudo tee /proc/acpi/call
\_SB.WMI1.WMAA 0 0 0x00000b04

Notice the ‘1’ in the command 4th digit from left. 0x00000b04 is off and 0x00010b04 is on. Print the output as well sudo cat /proc/acpi/call Since it has the return status from the command.

wasakakero · 2019-04-23T15:28:40Z

@aymanbagabas You were right!, so entering 2 times "echo "_SB.WMI1.WMAA 0 0 0x00010b04" | sudo tee /proc/acpi/call" turned on the LED, entering the turn off command 2 times also works turning off the LED.

Here are the outputs:

Turning ON:

[wasakakero@localhost ~]$ echo "\_SB.WMI1.WMAA 0 0 0x00010b04" | sudo tee /proc/acpi/call
[sudo] password for wasakakero: 
\_SB.WMI1.WMAA 0 0 0x00010b04
[wasakakero@localhost ~]$ sudo cat /proc/acpi/call
[{0x00, 0x00, 0x00, 0x00}, {0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
[wasakakero@localhost ~]$ echo "\_SB.WMI1.WMAA 0 0 0x00010b04" | sudo tee /proc/acpi/call
\_SB.WMI1.WMAA 0 0 0x00010b04
[wasakakero@localhost ~]$ sudo cat /proc/acpi/call
[{0x00, 0x00, 0x00, 0x00}, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

Turning OFF

[wasakakero@localhost ~]$ echo "\_SB.WMI1.WMAA 0 0 0x00000b04" | sudo tee /proc/acpi/call
\_SB.WMI1.WMAA 0 0 0x00000b04
[wasakakero@localhost ~]$ sudo cat /proc/acpi/call
[{0x00, 0x00, 0x00, 0x00}, {0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
[wasakakero@localhost ~]$ echo "\_SB.WMI1.WMAA 0 0 0x00000b04" | sudo tee /proc/acpi/call
\_SB.WMI1.WMAA 0 0 0x00000b04
[wasakakero@localhost ~]$ sudo cat /proc/acpi/call
[{0x00, 0x00, 0x00, 0x00}, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

aymanbagabas · 2019-04-24T16:51:31Z

@aymanbagabas sure thing, here it is:

dmesg.txt

I don't see any micmute event triggered in the log? Also try xdotool key XF86AudioMicMute since the led is independent of the key, it would toggle the led. You could also try muting mic from settings.

wasakakero · 2019-04-24T16:56:47Z

@aymanbagabas those "setkey" events I'm sure you can see is me pressing the micmute button, bear in mind as explained before that the micmute key works without issue, but the LED is not.

xdotool worked to mute/unmute the mic just as if I were pressing the key, but didn't turn on the led.

aymanbagabas · 2019-04-24T17:09:52Z

@aymanbagabas those "setkey" events I'm sure you can see is me pressing the micmute button, bear in mind as explained before that the micmute key works without issue, but the LED is not.

xdotool worked to mute/unmute the mic just as if I were pressing the key, but didn't turn on the led.

Do you get those "setkey" events from micmute key only or others as well? What is the output of these commands? Do you have a leds directory?

$ ls /sys/devices/platform/huawei-wmi/
$ ls /sys/devices/platform/huawei-wmi/leds
$ echo 0 | sudo tee /sys/devices/platform/huawei-wmi/leds/platform::micmute/brightness
$ echo 1 | sudo tee /sys/devices/platform/huawei-wmi/leds/platform::micmute/brightness

Could you also use evtest to test micmute key? Run sudo evtest then select Huawei WMI hotkeys press your hotkeys.

aymanbagabas · 2019-04-24T17:20:15Z

The way this works is, the LED is hooked to alsa where it triggers the micmute function from the driver. However, there aren't any calls to that function and no errors given. Which means either no micmute event given, but you did, or something with the led subsystem. Or something off with the driver

wasakakero · 2019-04-24T18:02:17Z

@aymanbagabas so I checked, the setkey events happens with:

Brithness (on and off)
Keyboard backlight
Micmute
Wifi (on and off)
PC Manager key

All of these keys work fine except for maybe PC Manager because I don't have anything assigned to it anyways, I believe.

Evtest showed keypresses in the same keys where setkey events happened, except for keyboard backlight.

Also Volume up, down, mute and the key that does screen changes (F8 in my device) do not appear here either if that helps.

All keys work as intended except for obviously, the LED.

Select the device event number [0-12]: 7
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Huawei WMI hotkeys"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 171 (KEY_CONFIG)
    Event code 190 (KEY_F20)
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event code 238 (KEY_WLAN)
    Event code 240 (KEY_UNKNOWN)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1556128578.624214, type 4 (EV_MSC), code 4 (MSC_SCAN), value 287
Event: time 1556128578.624214, type 1 (EV_KEY), code 190 (KEY_F20), value 1
Event: time 1556128578.624214, -------------- SYN_REPORT ------------
Event: time 1556128578.624233, type 1 (EV_KEY), code 190 (KEY_F20), value 0
Event: time 1556128578.624233, -------------- SYN_REPORT ------------
Event: time 1556128591.313284, type 4 (EV_MSC), code 4 (MSC_SCAN), value 281
Event: time 1556128591.313284, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 1
Event: time 1556128591.313284, -------------- SYN_REPORT ------------
Event: time 1556128591.313295, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0
Event: time 1556128591.313295, -------------- SYN_REPORT ------------
Event: time 1556128591.943256, type 4 (EV_MSC), code 4 (MSC_SCAN), value 282
Event: time 1556128591.943256, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
Event: time 1556128591.943256, -------------- SYN_REPORT ------------
Event: time 1556128591.943279, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
Event: time 1556128591.943279, -------------- SYN_REPORT ------------
Event: time 1556128603.824231, type 4 (EV_MSC), code 4 (MSC_SCAN), value 289
Event: time 1556128603.824231, type 1 (EV_KEY), code 238 (KEY_WLAN), value 1
Event: time 1556128603.824231, -------------- SYN_REPORT ------------
Event: time 1556128603.824254, type 1 (EV_KEY), code 238 (KEY_WLAN), value 0
Event: time 1556128603.824254, -------------- SYN_REPORT ------------
Event: time 1556128604.704216, type 4 (EV_MSC), code 4 (MSC_SCAN), value 289
Event: time 1556128604.704216, type 1 (EV_KEY), code 238 (KEY_WLAN), value 1
Event: time 1556128604.704216, -------------- SYN_REPORT ------------
Event: time 1556128604.704229, type 1 (EV_KEY), code 238 (KEY_WLAN), value 0
Event: time 1556128604.704229, -------------- SYN_REPORT ------------
Event: time 1556128608.530305, type 4 (EV_MSC), code 4 (MSC_SCAN), value 28a
Event: time 1556128608.530305, type 1 (EV_KEY), code 171 (KEY_CONFIG), value 1
Event: time 1556128608.530305, -------------- SYN_REPORT ------------
Event: time 1556128608.530334, type 1 (EV_KEY), code 171 (KEY_CONFIG), value 0
Event: time 1556128608.530334, -------------- SYN_REPORT ------------

echo 1 | sudo tee /sys/devices/platform/huawei-wmi/leds/platform::micmute/brightness turns on the LED, 0 turns it off.

aymanbagabas · 2019-04-24T18:16:52Z

Thank you for your collaboration!

Also Volume up, down, mute and the key that does screen changes (F8 in my device) do not appear here either if that helps.

That's because, on newer models, these keys are being treated as regular keyboard keys. Old models like Matebook X (2017) does not where it needs the driver for these to work.

All keys work as intended except for obviously, the LED.

Is pulseaudio running? What DE you're using?

echo 1 | sudo tee /sys/devices/platform/huawei-wmi/leds/platform::micmute/brightness turns on the LED, 0 turns it off.

This means nothing wrong with the driver

wasakakero · 2019-04-24T18:17:27Z

@aymanbagabas PulseAudio is indeed running, I'm on KDE.

aymanbagabas · 2019-04-24T18:28:28Z

@aymanbagabas PulseAudio is indeed running, I'm on KDE.

Try using the GUI settings to toggle mic mute. At this point, I can't think of anything that would cause this behavior. I'm using Gnome and changing the micmute from settings changes the LED accordingly. As I said, the driver hooks with ALSA and that's where ALSA takes control and changes the LED to match the sound system. Are you running the latest updates? What distro you using?

wasakakero · 2019-04-24T18:33:02Z

@aymanbagabas I tired both the GUI and Alsamixer but the LED didn't work.

Perhaps this has to do with comment #7 (comment) ?

Edit: I'm updated up until April 22th which is the last time I did an update, I'm on Fedora.

nekr0z · 2019-04-24T19:52:09Z

I'm using Gnome and changing the micmute from settings changes the LED accordingly.

KDE shouldn't be any different, and indeed isn't in my case, so I bet it's laptop model specific.

aymanbagabas · 2019-04-24T21:26:18Z

Perhaps this has to do with comment #7 (comment) ?

No, if it was, toggling the led using echo 1 | sudo tee /sys/devices/platform/huawei-wmi/leds/platform::micmute/brightness wouldn't work. I worked around that issue by checking the return bit every time the driver run a command.

It's the sound subsystem, not that anything's wrong with it, but we need to hook up the Matebook D sound system to the linux sound driver. See this. Probably @nekr0z laptop has the same sound module as mine. That's why it works.

@wasakakero @nekr0z could you please give the output of alsa-info.sh

wasakakero · 2019-04-24T23:26:50Z

@aymanbagabas here is mine: http://alsa-project.org/db/?f=0f1f4274a6b8d9a594c7b4a388cc87712713aba9

As a side note, I have experienced a lot of crackling noise in my Mic when I speak since I first installed Fedora, not world ending but noticeable, just wondering if any of you experience the same with the MBX and where would it be best to report to.

aymanbagabas · 2019-04-24T23:42:26Z

@aymanbagabas here is mine: http://alsa-project.org/db/?f=0f1f4274a6b8d9a594c7b4a388cc87712713aba9

Thank you!

As a side note, I have experienced a lot of crackling noise in my Mic when I speak since I first installed Fedora, not world ending but noticeable, just wondering if any of you experience the same with the MBX and where would it be best to report to.

First, I would search the internet if anyone had the same/similar issue and see. See this and this. If no luck and you couldn't find any resources on the internet, I would start by submitting a bug to the ALSA project.

I haven't experienced such a problem with my Matebook. The recorded sound coming from the microphone sounds clear and normal.

nekr0z · 2019-04-25T04:21:11Z

could you please give the output of alsa-info.sh

http://alsa-project.org/db/?f=be4acc627c836fd0205f5f9ee72eac354a27be0a

aymanbagabas · 2019-04-25T14:06:37Z

@nekr0z I'm curious to know how you got the led to work. Did it work right after you upgraded to 5.0?

Because these three lines in patch_realtek.c are the ones responsible for hooking the led to ALSA. The Matebook 13 has this id Subsystem Id: 0x19e5320d and the Matebook D has Subsystem Id: 0x19e53207. These were taken from alsa-info.sh

To make this generic to all Huawei laptops, we have to patch that file with something like this

SND_PCI_QUIRK_VENDOR(0x19e5, "Huawei laptop", ALC255_FIXUP_MIC_MUTE_LED),

Where 0x19e5 is the vendor id special to Huawei laptops.

nekr0z · 2019-04-25T14:21:04Z

I'm curious to know how you got the led to work. Did it work right after you upgraded to 5.0?

It started working right after I updated to 5.0 and installed your driver version 2.0. I honestly didn't test with 5.0 and driver v1. But if I rmmod the driver, it stops working.

aymanbagabas · 2019-04-25T15:46:57Z

@wasakakero I know you're using fedora, so what kernel version you using? uname -a.

I'm gonna compile a patched version of snd-hda-codec-realtek for you to test the LED. If you want to compile it you're self I'll be glad to help you out. Thank you guys for your contributions!

aymanbagabas · 2019-04-25T15:50:34Z

It started working right after I updated to 5.0 and installed your driver version 2.0. I honestly didn't test with 5.0 and driver v1. But if I rmmod the driver, it stops working.

You mean the one from master right?

nekr0z · 2019-04-25T16:31:38Z

You mean the one from master right?

No, it worked with released version 2.0, too. And it works with master, yes.

wasakakero · 2019-04-25T18:10:21Z

@aymanbagabas My kernel version should be Linux localhost.localdomain 5.0.7-200.fc29.x86_64 #1 SMP Mon Apr 8 15:40:59 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

aymanbagabas · 2019-04-25T18:30:54Z

snd-hda-codec-realtek.zip
@wasakakero please use this compiled module to test the LED. Move snd-hda-codec-realtek.ko to /lib/modules/5.0.7-200.fc29.x86_64/updates/ then execute sudo depmod -a and reboot.

wasakakero · 2019-04-25T18:47:58Z

@aymanbagabas Thank you for the comprehensive instructions.

I've done as instructed and the LED is still not working.

As a side note on your comment I see you mentioned "ALC255" but as far as I can see mine uses "ALC256"

aymanbagabas · 2019-04-25T20:50:36Z

@aymanbagabas Thank you for the comprehensive instructions.

I've done as instructed and the LED is still not working.

Could you provide dmesg, cat /sys/devices/platform/huawei-wmi/leds/platform::micmute/trigger, and modinfo snd-hda-codec-realtek.

As a side note on your comment I see you mentioned "ALC255" but as far as I can see mine uses "ALC256"

You're right, ALC255_FIXUP_MIC_MUTE_LED is used. But this one is different, this refers to platform specific micmute led function. In this case, it should call the led function in the driver. Now idk why they have it "ALC255" really it's just a name.

Edit: I might've given you the wrong file please try this one. I'm sorry
snd-hda-codec-realtek.zip

wasakakero · 2019-04-25T21:03:00Z

@aymanbagabas I tried with the new file, didn't work.

Please find attached the outputs.

dmesg
micmute trigger
modinfo

aymanbagabas · 2019-04-25T22:45:34Z

@aymanbagabas I tried with the new file, didn't work.

Please find attached the outputs.

dmesg
micmute trigger
modinfo

[    5.649069] audit: type=1400 audit(1556225843.630:65): avc:  denied  { module_load } for  pid=722 comm="systemd-udevd" path="/usr/lib/modules/5.0.7-200.fc29.x86_64/updates/snd-hda-codec-realtek.ko" dev="dm-0" ino=3014694 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=system permissive=0

SELinux prevents probing the module. Maybe because it was compiled in different machines?!

Could you please try the following and then output dmesg:

$ sudo setenforce 0
$ sudo modprobe snd-hda-codec-realtek

Then try micmute 🤞

wasakakero · 2019-04-25T23:07:28Z

So I did that, didn't work.

BUT

I disabled SELinux in /etc/selinux/config added the mod using depmod -a just to e extra sure, rebooted, loaded the WMI Driver.

Micmute and micmute LED worked.

aymanbagabas · 2019-04-25T23:15:28Z

So I did that, didn't work.

BUT

I disabled SELinux in /etc/selinux/config added the mod using depmod -a just to e extra sure, rebooted, loaded the WMI Driver.

Micmute and micmute LED worked.

Awesome! You nailed it! Thank you for your work

I guess now that we 'kinda' resolved this issue, we will leave it open until it gets patched in upstream.

aymanbagabas · 2019-05-13T20:41:49Z

Submitted a patch to upstream here
closing this one 👍

aymanbagabas mentioned this issue Apr 17, 2019

Legacy interface #9

Open

aymanbagabas added the bug Something isn't working label Apr 17, 2019

aymanbagabas closed this as completed May 13, 2019

aymanbagabas mentioned this issue Sep 2, 2019

[KPL-W0X] micmute LED doesn't activate automatically #20

Closed

Micmute led on Matebook D #7

Micmute led on Matebook D #7

Comments

wasakakero commented Apr 15, 2019

aymanbagabas commented Apr 15, 2019

wasakakero commented Apr 15, 2019

aymanbagabas commented Apr 15, 2019

wasakakero commented Apr 15, 2019

aymanbagabas commented Apr 15, 2019

aymanbagabas commented Apr 15, 2019 • edited Loading

wasakakero commented Apr 15, 2019 • edited Loading

aymanbagabas commented Apr 17, 2019

wasakakero commented Apr 18, 2019

aymanbagabas commented Apr 22, 2019

wasakakero commented Apr 22, 2019

aymanbagabas commented Apr 22, 2019

wasakakero commented Apr 22, 2019

aymanbagabas commented Apr 23, 2019

wasakakero commented Apr 23, 2019

aymanbagabas commented Apr 23, 2019

wasakakero commented Apr 23, 2019

aymanbagabas commented Apr 23, 2019

wasakakero commented Apr 23, 2019 • edited Loading

aymanbagabas commented Apr 23, 2019

aymanbagabas commented Apr 23, 2019 • edited Loading

wasakakero commented Apr 23, 2019

wasakakero commented Apr 23, 2019

aymanbagabas commented Apr 23, 2019

aymanbagabas commented Apr 23, 2019

wasakakero commented Apr 23, 2019

aymanbagabas commented Apr 23, 2019

wasakakero commented Apr 23, 2019

aymanbagabas commented Apr 24, 2019 • edited Loading

wasakakero commented Apr 24, 2019

aymanbagabas commented Apr 24, 2019

aymanbagabas commented Apr 24, 2019

wasakakero commented Apr 24, 2019

aymanbagabas commented Apr 24, 2019

wasakakero commented Apr 24, 2019

aymanbagabas commented Apr 24, 2019

wasakakero commented Apr 24, 2019 • edited Loading

nekr0z commented Apr 24, 2019

aymanbagabas commented Apr 24, 2019

wasakakero commented Apr 24, 2019

aymanbagabas commented Apr 24, 2019

nekr0z commented Apr 25, 2019

aymanbagabas commented Apr 25, 2019

nekr0z commented Apr 25, 2019

aymanbagabas commented Apr 25, 2019

aymanbagabas commented Apr 25, 2019

nekr0z commented Apr 25, 2019

wasakakero commented Apr 25, 2019

aymanbagabas commented Apr 25, 2019

wasakakero commented Apr 25, 2019 • edited Loading

aymanbagabas commented Apr 25, 2019 • edited Loading

wasakakero commented Apr 25, 2019

aymanbagabas commented Apr 25, 2019

wasakakero commented Apr 25, 2019

aymanbagabas commented Apr 25, 2019

aymanbagabas commented May 13, 2019

aymanbagabas commented Apr 15, 2019 •

edited

Loading

wasakakero commented Apr 15, 2019 •

edited

Loading

wasakakero commented Apr 23, 2019 •

edited

Loading

aymanbagabas commented Apr 23, 2019 •

edited

Loading

aymanbagabas commented Apr 24, 2019 •

edited

Loading

wasakakero commented Apr 24, 2019 •

edited

Loading

wasakakero commented Apr 25, 2019 •

edited

Loading

aymanbagabas commented Apr 25, 2019 •

edited

Loading