conqp / amd-sfh-hid-dkms

Linux kernel driver for the AMD Sensor Fusion Hub.
7 stars 3 forks source link

Sensors stop working when using this module, while attempting to detect lid flip #3

Open JosephFerano opened 2 years ago

JosephFerano commented 2 years ago

Hi, first thank you for your work. I would appreciate some assistance with the lid flip functionality to detect the tablet mode. My current expectation is to be able to receive an event that has detected that the lid has been flipped more than 180 degrees. On the Win10 side, if the lid is folded past the 180 degrees, windows detects that the tablet has entered tablet mode.

My system:

Asus ROG Flow X13 (non eGPU) 5.14.9-arch1-g14 (This is a kernel provided by the Asus Linux group)

Here is the current status of what's working;

The accelerometer is working and when I run monitor-sensor it correctly detects orientation changes. I also enabled the ambient light sensor with the sensor_mask. However this is with included amd-sfh module in my kernel, not the one provided here.

    Waiting for iio-sensor-proxy to appear
+++ iio-sensor-proxy appeared
=== Has accelerometer (orientation: normal)
=== Has ambient light sensor (value: 0.000000, unit: lux)
=== No proximity sensor
    Accelerometer orientation changed: right-up
    Accelerometer orientation changed: normal
    Accelerometer orientation changed: bottom-up
    Accelerometer orientation changed: normal

When I try to install this module, all sensors stop working. Only thing I get from dmesg is the following

[ 1526.368027] amd_sfh: loading out-of-tree module taints kernel.
[ 1526.368131] amd_sfh: module verification failed: signature and/or required key missing - tainting kernel

Going back to the default module in the kernel, I can see that it's detecting other iio devices as well;

total 0
lrwxrwxrwx 1 root root 0 Oct  7 18:24 iio:device0 -> ../../../devices/0020:1022:0001.0003/HID-SENSOR-200083.3.auto/iio:device0
lrwxrwxrwx 1 root root 0 Oct  7 18:24 iio:device1 -> ../../../devices/0020:1022:0001.0001/HID-SENSOR-200073.1.auto/iio:device1
lrwxrwxrwx 1 root root 0 Oct  7 18:24 iio:device2 -> ../../../devices/0020:1022:0001.0002/HID-SENSOR-200076.2.auto/iio:device2
lrwxrwxrwx 1 root root 0 Oct  7 18:25 iio:device3 -> ../../../devices/0020:1022:0001.0004/HID-SENSOR-200041.4.auto/iio:device3
lrwxrwxrwx 1 root root 0 Oct  7 18:24 iio:device4 -> ../../../devices/0020:1022:0001.0005/HID-SENSOR-200011.5.auto/iio:device4
lrwxrwxrwx 1 root root 0 Oct  7 18:24 trigger0 -> ../../../devices/0020:1022:0001.0003/HID-SENSOR-200083.3.auto/trigger0
lrwxrwxrwx 1 root root 0 Oct  7 18:24 trigger1 -> ../../../devices/0020:1022:0001.0001/HID-SENSOR-200073.1.auto/trigger1
lrwxrwxrwx 1 root root 0 Oct  7 18:24 trigger2 -> ../../../devices/0020:1022:0001.0002/HID-SENSOR-200076.2.auto/trigger2
lrwxrwxrwx 1 root root 0 Oct  7 18:24 trigger3 -> ../../../devices/0020:1022:0001.0005/HID-SENSOR-200011.5.auto/trigger3
lrwxrwxrwx 1 root root 0 Oct  7 18:25 trigger4 -> ../../../devices/0020:1022:0001.0004/HID-SENSOR-200041.4.auto/trigger4

dmesg does not show any entries for sfh

Here's a higly abbreviated tree that hints as to what each sensor is, and they do seem to change in order on reboot;

iio:device0
├── in_accel_x_raw
iio:device1
├── in_anglvel_x_raw
iio:device2
├── in_magn_x_raw
iio:device3
├── in_illuminance_scale
├── in_intensity_hysteresis
iio:device4
├── in_proximity_raw

Which sensor do you think is the one most likely to be responsible for emitting the lid flip event? I grabbed your python script from here and tried playing around trying to read data from them, however, nothing happened when folding the lid. When pointing to the right accelerometer device it does show the orientation changes though.

This is what I have so far. I'm pretty new to this so if you have suggestions on how to reverse engineer those sensors to try and read the events they emit, I would great appreciate it.

Thank you for your time.

conqp commented 2 years ago

This driver does not provide a lid switch event device. You can always try the upstream driver instead (it's part of the latest kernels) and check whether it supports this. But last time I checked, it did not either. I have no clue, how the tablet mode detection works on Windows. Since there does not yet seem to be support for this on Linux, I wrote the script you linked to, so that I can do this manually.

JosephFerano commented 2 years ago

The reason I was investigating this driver was because on the windows side, I found a driver called AMD Sensor Hub which I uninstalled and reinstalled and subsequently the lid switch functionality stopped then resumed working. The device id for that driver is ACPI\AMDI0080 which I can see from the Linux side as well. So I figured that I should investigate ACPI drivers instead of the asus-wmi one. However, in light of your response, I'll start investigating that driver as a potential way to fix this, as apparently it's helping other Asus laptops unlock this functionality.

conqp commented 2 years ago

I also suspected, that the AMD SFH driver on windows maybe provides two independent accelerometers (one in the lid and one in the chassis) so one can calculate the lid position from their difference in angle. However, when I was in contact with the devs from AMD when the upstream driver was initially developed, I got no response on this issue (they neither confirmed, nor denied that the SFH provides two independent accelerometers to calculate the lid angle). Alas, I have the same issue as you on my HP Envy x360 13".

IvanDovgal commented 2 years ago

@JosephFerano I found way to get full-featured sw_tablet_mode support on asus rog flow x13. You can download patch here This patch a bit ugly, but it works!

conqp commented 2 years ago

Awesome. Thanks. I'll try to merge this into my driver over the weekend. I think that it'll be appreciated, if you also submit this patch upstream.