amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

schard · 2020-04-18 18:25:52

As maybe many of you, just like me, got annoyed by having to re-build the entire kernel when testing updates on the linux-sfh package, I took the time to write a DKMS package that ships the driver:
https://aur.archlinux.org/packages/amd-sfh-hid-dkms/
I tested it successfully with the stable kernel.
Please let me know if you encounter any bugs or errors.

Note on [Firmware Bug]: No sensors marked active!
If you do not get screen rotation to work with the driver and encouter the error message

[Firmware Bug]: No sensors marked active!

in your dmesg output, your laptop manufacturer probably missed to write information about sensors connected to the sensor hub into its corresponding P2C register.
Try loading the amd_sfh_hid module with an explicitely enabled primary accelerometer:

$ cat /etc/modprobe.d/amd_sfh.conf
options amd_sfh_hid sensor_mask=1

Be sure to have the modconf hook enabled in your /etc/mkinitcpio.conf for this to take effect.

Last edited by schard (2020-05-23 13:43:51)

Zamundaaa · 2020-07-05 13:58:47

Thank you for doing this! It looks like the driver will still take quite some time to be mainlined...

So, this doesn't seem to work properly on my HP Envy x360 13-ay0779ng (with a Ryzen 4700U). At first I had the "No sensors marked active!" problem, and creating amd_sfh.conf did solve that.
KDE Plasma also now recognizes the sensor in the settings, but it doesn't actually do anything. monitor-sensor shows this:

$ monitor-sensor
Waiting for iio-sensor-proxy to appear
+++ iio-sensor-proxy appeared
=== Has accelerometer (orientation: undefined)
=== No ambient light sensor
=== No proximity sensor

I tried with kernel 5.7.6 and 5.8rc3, same results.

Do note that I'm on Manjaro (unstable)... I know this forum is exclusively for Arch x86_64, but this seems like the sole place for support on this.

schard · 2020-07-06 15:06:51

Please provide a full dmesg log with the driver loaded.

Zamundaaa · 2020-07-06 15:32:20

https://gist.github.com/Zamundaaa/32019 … 1da2a0862a

schard · 2020-07-07 07:07:44

This looks okay, as far as I can tell.
It is possible that the accelerometer is connected to another port of the SFH on your device or that the accelerometer returns different data. You'll need to tinker with the driver yourself on your specific laptop model to find out (aka. reverse engineer it). Unfortunately AMD has not disclosed too much information on the inner workings of the SFH yet so that I don't know if there's a possibility to generically retrieve information about the connected sensor types and locations from the device apart from reading a certain P2C register as AMD does.

Last edited by schard (2020-07-07 07:08:35)

Zamundaaa · 2020-07-08 20:47:52

Well, I'll definitely try, after my exams. I'll post again if I need help (or if I made it work). Thanks so far!

jorges · 2020-08-20 10:57:01

Hi,
I have an HP x360 15-ds1063cl with a ryzen 4500u. I have installed the package but it doesn't seem to work here:

$ monitor-sensor
    Waiting for iio-sensor-proxy to appear
+++ iio-sensor-proxy appeared
=== Has accelerometer (orientation: undefined)
=== No ambient light sensor
=== No proximity sensor

I don't see the dmesg error you make reference to, but instead:

$ dmesg | grep sfh
[    3.973889] amd_sfh_pci: loading out-of-tree module taints kernel.
[    3.973913] amd_sfh_pci: module verification failed: signature and/or required key missing - tainting kernel
[    3.974133] amd-sfh-pci 0000:04:00.7: enabling device (0000 -> 0002)
[    3.976170] amd-sfh-pci 0000:04:00.7: AMD SFH device initialized
[    3.977736] amd-sfh-pci 0000:04:00.7: Sensor mask: 0x2bdff
[    3.977737] amd-sfh-pci 0000:04:00.7: Invalid sensors: 0x2bdf8

Is there anything I can try, except waiting for new versions of the drivers?
BTW, thanks for the effort with this package

jorges · 2020-08-20 11:04:17

dmesg.log

schard · 2020-08-20 11:07:18

You can try to build the v7 patch by AMD on your own.
Otherwise #5 might apply to your case as well.
In that case you can try to cycle the value of ACCEL_IDX in order to try other sensor ports on the SFH.

Update:
Your full dmesg shows an acceleromerter, gyroscope and magnetometer.
Maybe your device has the sensors connected in a different order on the SFH.
So you can try to set the ACCEL_IDX to 1 or 2 respectively.

Also what you can try, is to just enable only the accelerometer as decribed in my initial post.

Last edited by schard (2020-08-20 11:20:54)

jorges · 2020-08-20 12:09:15

schard wrote:

You can try to build the v7 patch by AMD on your own.
Otherwise #5 might apply to your case as well.
In that case you can try to cycle the value of ACCEL_IDX in order to try other sensor ports on the SFH.
Update:
Your full dmesg shows an acceleromerter, gyroscope and magnetometer.
Maybe your device has the sensors connected in a different order on the SFH.
So you can try to set the ACCEL_IDX to 1 or 2 respectively.
Also what you can try, is to just enable only the accelerometer as decribed in my initial post.

Thank you for your suggestions. By my lack of understanding of what you are referring to above, I think this might be over my current abilities. Maybe I do have to wait for the driver to stabilize and be included in the mainline kernel. I had hopes there would be simpler stuff (like the suggested option passed to the module, etc.)

PeerK · 2020-10-22 09:40:23

Hi,

do you see a possibility, to update the package to the new 5.9.1 kernel?

With the kernel 5.8.16 on a Lenovo Ideapad 5 flex (convertible), I face the same problem as others here:

"Iio-sensor-proxy" appears in monitor-sensor, but the detection of the orientation fails as well as the automatic rotation in case of the rotation of the convertible.

Thank you and kind regards

Last edited by PeerK (2020-10-22 09:41:10)

schard · 2020-10-22 09:50:05

This is a DKMS package and it works perfectly fine¹ with the latest kernel.

[1] Perfectly fine in so far, as the current implementation I refactored from AMD's upstream stuff allows. There still is no support for Renoir devices (4000x), just Picasso (3000x). I suspect the problem is, that the accelerometer is returning differently structured data on the former, resulting in a need to alter the static const u8 accel3_report_descriptor. But since AMD did not yet publish a datasheet for either sensor hub, there's nothing that I can do about that. You'll have to wait for the AMD devs to get the upstream implementation done.

Zamundaaa · 2021-01-02 01:32:52

Whelp, the implementation from AMD still doesn't work on Renoir. Just tried it with 5.11rc1

schard · 2021-01-04 18:06:53

Yeah, and they merged it upstream without the module parameter to override the sensor mask that I suggested and submitted.
Nice to know, that the release of 5.11 will break my screen rotation again.

progandy · 2021-01-04 18:51:13

schard wrote:

Yeah, and they merged it upstream without the module parameter to override the sensor mask that I suggested and submitted.
Nice to know, that the release of 5.11 will break my screen rotation again.

Keep your dkms version and you should not notice anything. Just make sure the driver name is the same so it will be replaced by dkms.

schard · 2021-01-04 19:43:41

Good to know that this works. Since my refactored version has a slightly different naming, I think that I will need to blacklist the upstream modules.
Anyway, I now took the time to submit my refactored version upstream as a patch on AMD's submission to 5.11.
Maybe it will see some attention.

schard · 2021-01-25 04:47:38

Update 2021-01-25
The latest version of the DKMS driver in the AUR now supports auto detection of the two known HP Envy x360 models (such as mine) that need quirks due to missing sensor information in the P2C register.
This means, that on those systems you can now just let the driver load automatically without specifying module parameters.
There has also been some major rewriting, such as merging the platform driver part into the PCI driver, resulting in only one kernel module to be built and laoded, following the model of the upstream version.
You can find the source code here.

Arch Linux

#1 2020-04-18 18:25:52

amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#2 2020-07-05 13:58:47

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#3 2020-07-06 15:06:51

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#4 2020-07-06 15:32:20

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#5 2020-07-07 07:07:44

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#6 2020-07-08 20:47:52

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#7 2020-08-20 10:57:01

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#8 2020-08-20 11:04:17

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#9 2020-08-20 11:07:18

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#10 2020-08-20 12:09:15

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#11 2020-10-22 09:40:23

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#12 2020-10-22 09:50:05

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#13 2021-01-02 01:32:52

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#14 2021-01-04 18:06:53

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#15 2021-01-04 18:51:13

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#16 2021-01-04 19:43:41

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

#17 2021-01-25 04:47:38

Re: amd-sfh-hid-dkms - DKMS version of the experimental AMD SFH driver

Board footer