Created attachment 1507558 [details] Journal report after bios update Description of problem: The HP Envy x360(Ryzen) uses an integrated accelerometer which get detected but probe fails with: lis3lv02d: unknown sensor type 0x0 hp_accel: probe of HPQ6007:00 failed with error -22 Possibly all HP touchscreen laptops with AMD processors are affected considering their Intel counterpart run out of box (https://h30434.www3.hp.com/t5/Notebook-Video-Display-and-Touch/HP-Zbook-15-external-monitor-connected-to-docking-station/td-p/4985667) Version-Release number of selected component (if applicable): 4.19.2 How reproducible: Always Steps to Reproduce: 1. Boot a AMD power HP Touchscreen Laptop 2. 3. Actual results: lis3lv02d: unknown sensor type 0x0 hp_accel: probe of HPQ6007:00 failed with error -22 Expected results: Accelerometer is probed and configured accordingly. Additional info: Tested with HP Envy x360 Ryzen 2500U
Created attachment 1507559 [details] acpidump data after bios update acpidump tested with scratch build kernel provided by Hans
(In reply to Luya Tshimbalanga from comment #0) > lis3lv02d: unknown sensor type 0x0 > hp_accel: probe of HPQ6007:00 failed with error -22 I do not think that those messages are the problem, they are about a driver for harddisk fall protection, which given that your device uses a SSD is probably not there. I guess the ACPI tables still advertise support for it even though the hardware is not there, causing these log messages. In order to figure out how to get accelerometer support working on your laptop I need some more info. First of all try running "monitor-sensor": If this just hangs at "Waiting for iio-sensor-proxy to appear" then press ctrl+c, if it prints some more things, please let me know what it prints and if it claims you've an accelerometer, try rotating the screen and see if it outputs anything. If monitor-sensors finds an accelerometer and prints orientation changes when rotating, then everything is working as it should. If not please provide the output of: lspci -nn lsusb ls /sys/bus/i2c/devices ls /sys/bus/iio/devices And then we will see form there. Note, some AMD devices use a "AMD Sensor Fusion Hub" pci-id: 1022:15e4 for which there does not seem to be a linux driver yet. So if your lspci output includes a device with those ids then chances are that is the problem. But please do provide the output of all requested commands in the case that monitor-sensor does not see an accelerometer.
(In reply to Hans de Goede from comment #2) > (In reply to Luya Tshimbalanga from comment #0) > > lis3lv02d: unknown sensor type 0x0 > > hp_accel: probe of HPQ6007:00 failed with error -22 > > I do not think that those messages are the problem, they are about a driver > for harddisk fall protection, which given that your device uses a SSD is > probably not there. I guess the ACPI tables still advertise support for it > even though the hardware is not there, causing these log messages. The laptop originally has HDD before swapping with the SSD. It seems like a bug such driver does not automatically disable when SSD is present. > First of all try running "monitor-sensor": > > If this just hangs at "Waiting for iio-sensor-proxy to appear" then press > ctrl+c, if it prints some more things, please let me know what it prints and > if it claims you've an accelerometer, try rotating the screen and see if it > outputs anything. Sadly it hangs. > > If monitor-sensors finds an accelerometer and prints orientation changes > when rotating, then everything is working as it should. > > If not please provide the output of: > > lspci -nn 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:15d0] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Device [1022:15d1] 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge [1022:1452] 00:01.6 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:15d3] 00:01.7 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:15d3] 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge [1022:1452] 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:15db] 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:15dc] 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:15e8] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:15e9] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:15ea] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:15eb] 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:15ec] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:15ed] 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:15ee] 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:15ef] 01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader [10ec:522a] (rev 01) 02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter [10ec:b822] 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev c4) 03:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:15de] 03:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Device [1022:15df] 03:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15e0] 03:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15e1] 03:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Device [1022:15e3] 03:00.7 Non-VGA unclassified device [0000]: Advanced Micro Devices, Inc. [AMD] Device [1022:15e4] 04:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 61) > lsusb Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 0bda:b00b Realtek Semiconductor Corp. Bus 003 Device 002: ID 04f2:b634 Chicony Electronics Co., Ltd Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > ls /sys/bus/i2c/devices i2c-0 i2c-2 i2c-4 i2c-6 i2c-8 i2c-ELAN0732:00 i2c-1 i2c-3 i2c-5 i2c-7 i2c-9 > ls /sys/bus/iio/devices Not listed. However, booting Windows 10 shows the screen rotating when positioning the laptop in portrait. Not sure if it is an emulation. > And then we will see form there. > > Note, some AMD devices use a "AMD Sensor Fusion Hub" pci-id: 1022:15e4 for > which there does not seem to be a linux driver yet. So if your lspci output > includes a device with those ids then chances are that is the problem. It looks like we found the issue from the lspci -nn extract: 03:00.7 Non-VGA unclassified device [0000]: Advanced Micro Devices, Inc. [AMD] Device [1022:15e4]
Ok, so I indeed believe that this is caused by missing support for the AMD fusion sensor hub. I've send a message to AMD's Bridgman who is a point of contact for FOSS GPU drivers if he can put me in contact with someone inside AMD who knows more about the AMD fusion sensor hub.
Thanks Hans!
Rename the bug to match comment #4.
(In reply to Hans de Goede from comment #4) > Ok, so I indeed believe that this is caused by missing support for the AMD > fusion sensor hub. > > I've send a message to AMD's Bridgman who is a point of contact for FOSS GPU > drivers if he can put me in contact with someone inside AMD who knows more > about the AMD fusion sensor hub. With some researches, I found these informations: https://www.kionix.com/sensor-fusion and https://github.com/RohmSemiconductor/Linux-Kernel-Input-Drivers
Hi, (In reply to Luya Tshimbalanga from comment #7) > (In reply to Hans de Goede from comment #4) > > Ok, so I indeed believe that this is caused by missing support for the AMD > > fusion sensor hub. > > > > I've send a message to AMD's Bridgman who is a point of contact for FOSS GPU > > drivers if he can put me in contact with someone inside AMD who knows more > > about the AMD fusion sensor hub. > > With some researches, I found these informations: > https://www.kionix.com/sensor-fusion and > https://github.com/RohmSemiconductor/Linux-Kernel-Input-Drivers I do not believe that those are related to the AMD sensor-hub, they just happen to both use "sensor fusion" as some sort of marketing term. Unfortunately I've not heard anything back from AMD yet wrt this. Regards, Hans
Oh well. Hopefully AMD will reply sooner.
Any update from the AMD side?
(In reply to Luya Tshimbalanga from comment #10) > Any update from the AMD side? Unfortunately not, and without any documentation it is going to be quite hard to support this.
I found an Arch linux page (https://wiki.archlinux.org/index.php/HP_Envy_X360_15-bq102ng) mentioning STM Sensor hub. Maybe investigating there?
(In reply to Luya Tshimbalanga from comment #12) > I found an Arch linux page > (https://wiki.archlinux.org/index.php/HP_Envy_X360_15-bq102ng) mentioning > STM Sensor hub. Maybe investigating there? That is for s slightly different model Envy X360, which has sensors connected to the i2c bus, as the "ls /sys/bus/i2c/devices" you have done shows, your model's sensors are not connected to the i2c bus.
Interesting, I wonder why that little change on the newer Envy X360.
Same issue on 13 inch Envy, to the PCI-E ID, hope you hear something from AMD soon :D
Hello all, I am also experiencing this issue on the HP Envy x360(Ryzen). Is there still any hope of AMD responding?
The Sensor Fusion Hub is correctly identified on kernel 4.20.14 displayed a more detailed information: 03:00.7 Non-VGA unclassified device [0000]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2/Renoir Sensor Fusion Hub [1022:15e4] It looks like the info is from the linux-firmware. Still no driver.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora XX has now been rebased to 5.0.6 Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
Done. The issue still affects all Fedora release and other distributions.
Hi Hans, Just noticed this link https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-next&id=529766e0a0114438887382a68d97341fbf8349fb via Phoronix post (https://www.phoronix.com/scan.php?page=news_item&px=AMD-MP2-I2C-Linux-5.2). Not sure if this is the missing driver as I would like to test it.
(In reply to Luya Tshimbalanga from comment #20) > Hi Hans, > > Just noticed this link > https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/commit/?h=i2c/ > for-next&id=529766e0a0114438887382a68d97341fbf8349fb via Phoronix post > (https://www.phoronix.com/scan.php?page=news_item&px=AMD-MP2-I2C-Linux-5.2). > Not sure if this is the missing driver as I would like to test it. I'm afraid that that is not the driver you need, that is an i2c controller driver, not a driver for sensors attached to the fusion-hub.
You are right. Still waiting for the driver in question.
Could this be it? https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-next&id=529766e0a0114438887382a68d97341fbf8349fb
(In reply to hpryzen5 from comment #23) > Could this be it? > > https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/commit/?h=i2c/ > for-next&id=529766e0a0114438887382a68d97341fbf8349fb Oh, should read first... sorry. I see it's not. Got over-excited I guess. Really hoping the driver'll show up.
According to Alex from AMD, the driver for the Sensor Fusion HUB will be available around August. https://lists.freedesktop.org/archives/amd-gfx/2019-May/034431.html
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs. Fedora 30 has now been rebased to 5.2.9-200.fc30. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31. If you experience different issues, please open a new bug report for those.
It is an upstream bug AMD developers are working on a driver which will be available possibly near the end of August. See Comment #25.
Okay, going to close this as upstream. Once the driver is upstream, it will be enabled in Fedora.
(In reply to Justin M. Forbes from comment #28) > Okay, going to close this as upstream. Once the driver is upstream, it will > be enabled in Fedora. Hello Justin, the driver needed for AMD Sensor Fusion Hub finally landed upstream but it is disabled on the latest snapshot i.e. 5.11.0-0.rc2.114.fc34.x86_64. Will it be possible to enable it? Thanks in advance.
@jforbes Testing a modified kernel 5.11.0-0.rc2.114.fc34.x86_64 with enabled AMD Sensor Fusion HUB module failed to run the sensors. lsmod | grep amd_sfh amd_sfh 24576 0 I don't know if the firmware is missing or something else needs to activate. Thanks for the help.
Reopening the bug as the sensor fusion module landed on upstream kernel, as tested on kernel 5.11.0-0.rc3.20210114git65f0d2414b70 snapshot with amd_sfh module enabled: lspci -knn 03:00.7 Non-VGA unclassified device [0000]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2/Renoir Sensor Fusion Hub [1022:15e4] Subsystem: Hewlett-Packard Company Device [103c:8497] Kernel driver in use: pcie_mp2_amd Kernel modules: amd_sfh lsmod | grep amd edac_mce_amd 90112 0 kvm_amd 380928 0 kvm 2207744 1 kvm_amd amdgpu 19922944 16 drm_ttm_helper 16384 1 amdgpu ttm 188416 2 amdgpu,drm_ttm_helper iommu_v2 36864 1 amdgpu gpu_sched 86016 1 amdgpu i2c_algo_bit 28672 1 amdgpu drm_kms_helper 638976 1 amdgpu drm 1359872 19 gpu_sched,drm_kms_helper,amdgpu,drm_ttm_helper,ttm ccp 274432 1 kvm_amd amd_sfh 36864 0 pinctrl_amd 73728 1 modinfo amd_sfh filename: /lib/modules/5.11.0-0.rc3.20210114git65f0d2414b70.125.amdsfh.fc33.x86_64/kernel/drivers/hid/amd-sfh-hid/amd_sfh.ko.xz author: Sandeep Singh <Sandeep.singh> author: Shyam Sundar S K <Shyam-sundar.S-k> license: Dual BSD/GPL description: AMD(R) PCIe MP2 Communication Driver rhelversion: 8.99 alias: pci:v00001022d000015E4sv*sd*bc*sc*i* depends: retpoline: Y intree: Y name: amd_sfh vermagic: 5.11.0-0.rc3.20210114git65f0d2414b70.125.amdsfh.fc33.x86_64 SMP mod_unload monitor-sensors failed to detect sensor fusion Upstream bug report is also updated.
What is the output of: ls -l /sys/bus/pci/drivers/pcie_mp2_amd ls -l /sys/bus/hid/devices ls -l /sys/bus/iio/devices When running a kernel with the driver ?
ls -l /sys/bus/pci/drivers/pcie_mp2_amd total 0 lrwxrwxrwx. 1 root root 0 Jan 16 14:16 0000:03:00.7 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.7 --w-------. 1 root root 4096 Jan 16 14:16 bind lrwxrwxrwx. 1 root root 0 Jan 16 14:16 module -> ../../../../module/amd_sfh --w-------. 1 root root 4096 Jan 16 14:16 new_id --w-------. 1 root root 4096 Jan 16 14:16 remove_id --w-------. 1 root root 4096 Jan 16 14:16 uevent --w-------. 1 root root 4096 Jan 16 14:16 unbind ls -l /sys/bus/hid/devices total 0 lrwxrwxrwx. 1 root root 0 Jan 16 14:16 0018:04F3:264C.0001 -> ../../../devices/platform/AMDI0010:00/i2c-0/i2c-ELAN0732:00/0018:04F3:264C.0001 ls -l /sys/bus/iio/devices ls: cannot access '/sys/bus/iio/devices': No such file or directory Somehow iio devices are not detected.
Ok, what is the output of: ls -l '/sys/bus/hid/devices/0018:04F3:264C.0001' ? And can you attach dmesg output from a kernel with the driver ?
Created attachment 1748195 [details] dmesg output from 5.11.0-0.rc3.20210114git65f0d2414b70 with amd_sfh module ls -l '/sys/bus/hid/devices/0018:04F3:264C.0001' lrwxrwxrwx. 1 root root 0 Jan 16 10:02 /sys/bus/hid/devices/0018:04F3:264C.0001 -> ../../../devices/platform/AMDI0010:00/i2c-0/i2c-ELAN0732:00/0018:04F3:264C.0001
So as discussed here: https://bugzilla.kernel.org/showa_bug.cgi?id=199715 Here is a scratch-build of the Fedora 5.11 kernel with patches to add a module parameter to force the amd_sfh module to consider certain sensors to be present: https://koji.fedoraproject.org/koji/taskinfo?taskID=59896010 (Note this is still building atm). Here are some generic instructions for installing a kernel scratch-build directly from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Please try this new kernel with: "amd_sfh.sensor_mask=0x80007" added to the kernel commandline. You should be able to test the accelerometer and ambient-light-sensor with the monitor-sensor command. For the gyro and compass you will likely need to use "cat" from the commandline on the "raw" sysfs-files of the corresponding /sys/bus/iio/devices devices doing something like: watch -n .2 cat /sys/bus/iio/devices/device-foo/something_in_raw And for sensors which have x + y + z values something like: watch -n .2 cat /sys/bus/iio/devices/device-foo/something_in_?_raw So that you see all 3 x + y + z values at the same time. For the magneto values (compass) you expect the x and y values to change if you sit the laptop on the desk and then rotate it while keeping it sitting on the desk, while the values should stat more or less the same when you do not move the laptop. I'm not sure what to expect for the gyro values...
Note the scratch build is finished now.
After installing the kernel from scratch build: cat /proc/cmdline BOOT_IMAGE=(hd0,gpt4)/boot/vmlinuz-5.11.0-0.rc3.20210114git65f0d2414b70.125.rhbz1651886.fc34.x86_64 root=UUID=76d5edeb-8ecb-4289-8fb1-8c481fbb405b ro rootflags=subvol=root rhgb quiet amd_sfh.sensor_mask=0x80007 and insuring there is no conf specific to this report: ls /etc/modprobe.d/ firewalld-sysctls.conf kvm.conf lockd.conf mlx4.conf nvdimm-security.conf truescale.conf monitor-sensor command returned nothing other than "Waiting for iio-sensor-proxy to appear". iio is still unlisted ls /sys/bus/ ac97/ container/ hdaudio/ memory/ pci_express/ serial/ usb/ xen-backend/ acpi/ cpu/ hid/ mipi-dsi/ pcmcia/ serio/ usb-serial/ auxiliary/ dax/ i2c/ mmc/ platform/ snd_seq/ virtio/ cec/ edac/ machinecheck/ node/ pnp/ soundwire/ wmi/ clockevents/ event_source/ mdio_bus/ nvmem/ scsi/ spi/ workqueue/ clocksource/ gpio/ media/ pci/ sdio/ typec/ xen/ ls -l /sys/bus/hid/devices/0018\:04F3\:264C.0001/ total 0 -r--r--r--. 1 root root 4096 Jan 17 12:49 country lrwxrwxrwx. 1 root root 0 Jan 17 12:37 driver -> ../../../../../../bus/hid/drivers/hid-multitouch drwxr-xr-x. 3 root root 0 Jan 17 04:37 hidraw drwxr-xr-x. 6 root root 0 Jan 17 04:37 input -r--r--r--. 1 root root 4096 Jan 17 12:49 modalias drwxr-xr-x. 2 root root 0 Jan 17 12:49 power drwxr-xr-x. 3 root root 0 Jan 17 04:37 power_supply -rw-r--r--. 1 root root 4096 Jan 17 12:49 quirks -r--r--r--. 1 root root 4096 Jan 17 12:37 report_descriptor lrwxrwxrwx. 1 root root 0 Jan 17 04:37 subsystem -> ../../../../../../bus/hid -rw-r--r--. 1 root root 4096 Jan 17 04:37 uevent It seems amd_sfh module is absent as noticed on lsmod | grep amd edac_mce_amd 90112 0 kvm_amd 380928 0 kvm 2191360 1 kvm_amd amdgpu 19836928 14 drm_ttm_helper 16384 1 amdgpu ttm 188416 2 amdgpu,drm_ttm_helper iommu_v2 36864 1 amdgpu gpu_sched 86016 1 amdgpu i2c_algo_bit 28672 1 amdgpu drm_kms_helper 638976 1 amdgpu drm 1355776 17 gpu_sched,drm_kms_helper,amdgpu,drm_ttm_helper,ttm ccp 274432 1 kvm_amd pinctrl_amd 73728 1 Maybe you forgot to enable it.
Sorry, I thought that the amd_sfh driver was enabled by default now, but it seems it only got enabled for the one test build for you. Here is a new build which has both my patches and has amd_sfh enabled: https://koji.fedoraproject.org/koji/taskinfo?taskID=59993254 Note this is still building atm, please let me know how things go with this build (testing instructions are the same as before).
(In reply to Hans de Goede from comment #39) > Sorry, I thought that the amd_sfh driver was enabled by default now, but it > seems it only got enabled for the one test build for you. Hopefully on a future update amd_sfh will be enabled by default once the test is successful. > > Here is a new build which has both my patches and has amd_sfh enabled: > https://koji.fedoraproject.org/koji/taskinfo?taskID=59993254 Thank you. Here is the report: cat /proc/cmdline BOOT_IMAGE=(hd0,gpt4)/boot/vmlinuz-5.11.0-0.rc3.20210114git65f0d2414b70.125.bz1651886_2.fc34.x86_64 root=UUID=76d5edeb-8ecb-4289-8fb1-8c481fbb405b ro rootflags=subvol=root rhgb quiet amd_sfh.sensor_mask=0x80007 Insuring that no custom conf related to the sensor is present: ls /etc/modprobe.d/ firewalld-sysctls.conf lockd.conf nvdimm-security.conf kvm.conf mlx4.conf truescale.conf For the first time, monitor-sensor finally detected the sensors: monitor-sensor 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: left-up Accelerometer orientation changed: bottom-up Accelerometer orientation changed: left-up Accelerometer orientation changed: normal The accelerometer is working although the desktop session did not autorotate. The ambient-light-sensor did nothing after switching to different rooms from light to dark. Showing the iio path: ls /sys/bus/iio/ devices drivers drivers_autoprobe drivers_probe uevent Here is the list of devices: Gyroscope --------- ls /sys/bus/iio/devices/iio\:device0/ buffer/ in_anglvel_z_raw dev name in_anglvel_hysteresis power/ in_anglvel_offset scan_elements/ in_anglvel_sampling_frequency subsystem/ in_anglvel_scale trigger/ in_anglvel_x_raw uevent in_anglvel_y_raw cat /sys/bus/iio/devices/iio\:device0/name gyro_3d cat /sys/bus/iio/devices/trigger0/name gyro_3d-dev0 Gyroscope value returned 0.0.0 (x.y.z) Ambient Sensor Light -------------------- ls /sys/bus/iio/devices/iio\:device1/ buffer in_intensity_offset dev in_intensity_sampling_frequency in_illuminance_hysteresis in_intensity_scale in_illuminance_offset name in_illuminance_raw power in_illuminance_sampling_frequency scan_elements in_illuminance_scale subsystem in_intensity_both_raw trigger in_intensity_hysteresis uevent cat /sys/bus/iio/devices/iio\:device1/name als cat /sys/bus/iio/devices/trigger1/name als-dev1 Test with cat /sys/bus/iio/devices/iio\:device1/in_illuminance_raw seems doing nothing despite switching to ligthin environment. Accelerometer ------------- ls /sys/bus/iio/devices/iio\:device2/ buffer in_accel_scale scan_elements current_timestamp_clock in_accel_x_raw subsystem dev in_accel_y_raw trigger in_accel_hysteresis in_accel_z_raw uevent in_accel_offset name in_accel_sampling_frequency power cat /sys/bus/iio/devices/iio\:device2/name accel_3d cat /sys/bus/iio/devices/trigger3/name accel_3d-dev2 Test with cat /sys/bus/iio/devices/iio\:device2/in_accel_x_raw successful. Test with cat /sys/bus/iio/devices/iio\:device2/in_accel_y_raw successful. Test with cat /sys/bus/iio/devices/iio\:device2/in_accel_z_raw successful. Magnetometer ------------ ls /sys/bus/iio/devices/iio\:device3/ buffer in_magn_sampling_frequency in_magn_z_raw subsystem dev in_magn_scale name trigger in_magn_hysteresis in_magn_x_raw power uevent in_magn_offset in_magn_y_raw scan_elements cat /sys/bus/iio/devices/iio\:device3/name magn_3d cat /sys/bus/iio/devices/trigger2/name magn_3d-dev3 Test with cat /sys/bus/iio/devices/iio:device3/in_magn_x_raw successful. Test with cat /sys/bus/iio/devices/iio:device3/in_magn_y_raw successful. Test with cat /sys/bus/iio/devices/iio:device3/in_magn_z_raw successful.
Overall, the sensors excluding ambient-light-sensors function but the GNOME Wayland session seem unable to recognize them.
Created attachment 1748632 [details] dmesg output from 5.11.0-0.rc3 with amd_sfh enabled On boot, a trackeback related to the sensors: [ 18.483366] Call Trace: [ 18.483371] dump_stack+0xae/0xe5 [ 18.483382] print_address_description.constprop.0+0x18/0x160 [ 18.483392] ? hid_report_raw_event+0x162/0x1050 [ 18.483401] kasan_report.cold+0x7f/0x10e [ 18.483410] ? hid_report_raw_event+0x162/0x1050 [ 18.483418] check_memory_region+0xf5/0x1d0 [ 18.483427] memset+0x20/0x40 [ 18.483435] hid_report_raw_event+0x162/0x1050 [ 18.483442] ? sensor_hub_raw_event+0x608/0xee0 [hid_sensor_hub] [ 18.483456] hid_input_report+0x296/0x500 [ 18.483463] ? lock_downgrade+0x6b0/0x6b0 [ 18.483472] amd_sfh_work+0x446/0x5e0 [amd_sfh] [ 18.483482] process_one_work+0x89f/0x1450 [ 18.483493] ? pwq_dec_nr_in_flight+0x260/0x260 [ 18.483500] ? lock_acquired+0x5d4/0xaf0 [ 18.483513] worker_thread+0x590/0xf80 [ 18.483523] ? __kthread_parkme+0xcb/0x1b0 [ 18.483530] ? process_one_work+0x1450/0x1450 [ 18.483538] kthread+0x368/0x440 [ 18.483544] ? _raw_spin_unlock_irq+0x24/0x40 [ 18.483552] ? kthread_create_worker_on_cpu+0xb0/0xb0 [ 18.483560] ret_from_fork+0x22/0x30 [ 18.483578] Allocated by task 365: [ 18.483583] kasan_save_stack+0x1b/0x40 [ 18.483590] ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 18.483596] amd_sfh_hid_client_init+0x505/0xb30 [amd_sfh] [ 18.483604] amd_mp2_pci_probe+0x1eb/0x250 [amd_sfh] [ 18.483611] local_pci_probe+0xd8/0x170 [ 18.483618] pci_device_probe+0x318/0x5c0 [ 18.483623] really_probe+0x224/0xc40 [ 18.483634] driver_probe_device+0x1f2/0x380 [ 18.483641] device_driver_attach+0x1df/0x250 [ 18.483647] __driver_attach+0xf6/0x260 [ 18.483652] bus_for_each_dev+0x114/0x180 [ 18.483658] bus_add_driver+0x352/0x570 [ 18.483663] driver_register+0x20f/0x390 [ 18.483667] do_one_initcall+0xfb/0x530 [ 18.483672] do_init_module+0x1ce/0x7a0 [ 18.483677] load_module+0x9841/0xa380 [ 18.483681] __do_sys_init_module+0x18b/0x220 [ 18.483686] do_syscall_64+0x33/0x40 [ 18.483691] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 18.483698] The buggy address belongs to the object at ffff88811ee71640 which belongs to the cache kmalloc-16 of size 16 [ 18.483703] The buggy address is located 15 bytes inside of 16-byte region [ffff88811ee71640, ffff88811ee71650) [ 18.483710] The buggy address belongs to the page: [ 18.483714] page:00000000475e13d3 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11ee71 [ 18.483721] flags: 0x17ffffc0000200(slab) [ 18.483728] raw: 0017ffffc0000200 ffffea000491f940 0000000200000002 ffff888100041b40 [ 18.483733] raw: 0000000000000000 0000000080800080 00000001ffffffff 0000000000000000 [ 18.483736] page dumped because: kasan: bad access detected [ 18.483741] Memory state around the buggy address: [ 18.483745] ffff88811ee71500: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc [ 18.483749] ffff88811ee71580: 00 00 fc fc 00 00 fc fc 00 00 fc fc fb fb fc fc [ 18.483752] >ffff88811ee71600: 00 00 fc fc 00 00 fc fc 00 07 fc fc 00 00 fc fc [ 18.483756] ^ [ 18.483759] ffff88811ee71680: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc [ 18.483763] ffff88811ee71700: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc [ 18.483766] ================================================================== On a side note, is it safe to disable "hp_accel" since it was for hard drive (replaced by a solid state drive) and any idea about lis3lv02d?
Thank you for testing. About GNOME not responding to the accelerometer this could be a number of things: 1. Please check that you have not enabled the rotation-lock in the system-menu (the panel's top-right menu). 2. There was a bug in gnome-shell which may not be fixed in Fedora yet where it misbehaved if some input devices show up later, breaking rotation. Please try logging out and logging in again and then try using the accelerometer for display rotation without first plugging in say a mouse or something like that. 3. It could be that the kernel sees a SW_TABLET_MODE input device, if that is the case then the accelerometer is only honored when the device is folded into tablet mode. So you could try folding it into tablet mode. To check this run "sudo evemu-record" and then see if there is any device advertising SW_TABLET_MODE capability. A likely candidate for this is the "Intel Virtual Button driver" device. Although I wonder if that is used on AMD based laptops... Another candidate might be the "HP WMI" driver, but it is best to try all input devices. If you have a device advertising SW_TABLET_MODE then keep evemu-record running for that device and check that it changes when you fold the device into tablet-mode and back into laptop-mode again. GNOME-shell will only respond to the accelerometer when their either is no SW_TABLET_MODE device at all, or when SW_TABLET_MODE=1.
(In reply to Hans de Goede from comment #43) > Thank you for testing. > > About GNOME not responding to the accelerometer this could be a number of > things: > > 1. Please check that you have not enabled the rotation-lock in the > system-menu (the panel's top-right menu). > Rotation-lock is missing in the system-menu and the Display settings despite the presence of both accelerometer and magnetometer. > 2. There was a bug in gnome-shell which may not be fixed in Fedora yet where > it misbehaved if some input devices show up later, breaking rotation. Please > try logging out and logging in again and then try using the accelerometer > for display rotation without first plugging in say a mouse or something like > that. > All external inputs are unplugged and attempting to logging out and logging in again returns the same result: GNOME Shell does not rotate in addition of missing rotation-lock and using Super+o key. It looks like GNOME Shell in has an unresolved bug with broken rotation. > 3. It could be that the kernel sees a SW_TABLET_MODE input device, if that > is the case then the accelerometer is only honored when the device is folded > into tablet mode. So you could try folding it into tablet mode. To check > this run "sudo evemu-record" and then see if there is any device advertising > SW_TABLET_MODE capability. A likely candidate for this is the "Intel Virtual > Button driver" device. Although I wonder if that is used on AMD based > laptops... Another candidate might be the "HP WMI" driver, but it is best to > try all input devices. If you have a device advertising SW_TABLET_MODE then > keep evemu-record running for that device and check that it changes when you > fold the device into tablet-mode and back into laptop-mode again. > GNOME-shell will only respond to the accelerometer when their either is no > SW_TABLET_MODE device at all, or when SW_TABLET_MODE=1. sudo evemu-record Available devices: /dev/input/event0: Power Button /dev/input/event1: Lid Switch /dev/input/event2: Power Button /dev/input/event3: AT Translated Set 2 keyboard /dev/input/event4: SynPS/2 Synaptics TouchPad /dev/input/event5: Video Bus /dev/input/event6: ELAN0732:00 04F3:264C /dev/input/event7: ELAN0732:00 04F3:264C UNKNOWN /dev/input/event8: ELAN0732:00 04F3:264C UNKNOWN /dev/input/event9: ELAN0732:00 04F3:264C /dev/input/event10: HP Wireless hotkeys /dev/input/event11: HP WMI hotkeys /dev/input/event12: HP Wide Vision FHD Camera: HP W /dev/input/event13: HP Wide Vision FHD Camera: HP I /dev/input/event14: HD-Audio Generic HDMI/DP,pcm=3 /dev/input/event15: HD-Audio Generic Mic /dev/input/event16: HD-Audio Generic Headphone Select the device event number [0-16]: 11 # EVEMU 1.3 # Kernel: 5.11.0-0.rc3.20210114git65f0d2414b70.125.bz1651886_2.fc34.x86_64 # DMI: dmi:bvnAMI:bvrF.47:bd07/03/2020:br15.47:efr92.48:svnHP:pnHPENVYx360Convertible15-cp0xxx:pvr:rvnHP:rn8497:rvr92.48:cvnHP:ct31:cvrChassisVersion: # Input device name: "HP WMI hotkeys" # Input device ID: bus 0x19 vendor 0000 product 0000 version 0000 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event code 15 (SYN_MAX) # Event type 1 (EV_KEY) # Event code 138 (KEY_HELP) # Event code 141 (KEY_SETUP) # Event code 148 (KEY_PROG1) # Event code 153 (KEY_ROTATE_DISPLAY) # Event code 224 (KEY_BRIGHTNESSDOWN) # Event code 225 (KEY_BRIGHTNESSUP) # Event code 226 (KEY_MEDIA) # Event code 240 (KEY_UNKNOWN) # Event code 358 (KEY_INFO) # Event type 4 (EV_MSC) # Event code 4 (MSC_SCAN) # Event type 5 (EV_SW) # Event code 1 (SW_TABLET_MODE) # State 0 # Event code 5 (SW_DOCK) # State 0 # Properties: N: HP WMI hotkeys I: 0019 0000 0000 0000 P: 00 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 24 10 02 00 00 00 00 B: 01 00 00 00 00 07 00 01 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 40 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 00 00 00 00 00 00 00 00 B: 04 10 00 00 00 00 00 00 00 B: 05 22 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 ################################ # Waiting for events # ################################ HP WMI showed the device handles SW_TABLET_MODE but GNOME Shell does nothing.
Ok, so the problem here is that on 2-in-1s which report their mode through SW_TABLET_MODE gnome-shell will only do auto-rotation when SW_TABLET_MODE reports the device is in tablet-mode. IOW, when SW_TABLET_MODE=1 What happens if you monitor the "HP WMI hotkeys" device in evemu-record and then fold the display all the way around, so that the back of the display touches the back of the keyboard part ? This way you can hold the x360 as a tablet and then SW_TABLET_MODE should report 1. Once SW_TABLET_MODE reports 1 I would expect the display to start auto-rotating based on the accelerometer output. If SW_TABLET_MODE never reports 1, please file a new bug against the kernel for this and give me a link to the new bug, then we can discuss that issue in this new bug.
Same result as comment #44 hence a new filed bug. I noticed newer kernel https://koji.fedoraproject.org/koji/buildinfo?buildID=1670681 just came out and I wonder if that will make a difference.
(In reply to Hans de Goede from comment #43) > > 1. Please check that you have not enabled the rotation-lock in the > system-menu (the panel's top-right menu). > I found out rotation-lock is accessible via Super+o even thought the button is missing on GNOME Wayland but present on GNOME on X.
Here is a new build sratch-build of the latest 5.11-rc5 kernel with my amd_sfh patches and a patch to fix the SW_TABLET_MODE issue from bug 1918255 : https://koji.fedoraproject.org/koji/taskinfo?taskID=60556548 Note this is still building atm. This time the amd_sfh patches include a patch to automatically set the sensor_mask based on a DMI match, so when testing please make sure that you do NOT have "amd_sfh.sensor_mask=0x80007" on your kernel commandline (see "cat /proc/cmdline" output to verify). Please let me know how things go with this build. If for some reason you do not get any sensors in monitor-sensor again with this build, then there likely is something wrong with the DMI matching, in that case please retry with "amd_sfh.sensor_mask=5" added to your kernel commandline.
(In reply to Hans de Goede from comment #48) > Here is a new build sratch-build of the latest 5.11-rc5 kernel with my > amd_sfh patches and a patch to fix the SW_TABLET_MODE issue from bug 1918255 > : > https://koji.fedoraproject.org/koji/taskinfo?taskID=60556548 Thank you Hans. Here is the following result: No parameter related to amd_sfh present on boot $cat /proc/cmdline BOOT_IMAGE=(hd0,gpt4)/boot/vmlinuz-5.11.0-0.rc5.134.bz1651886_3.fc34.x86_64 root=UUID=76d5edeb-8ecb-4289-8fb1-8c481fbb405b ro rootflags=subvol=root rhgb quiet Modprobe related to AMD sensor fusion is absent: ls /etc/modprobe.d/ blacklist.conf kvm.conf mlx4.conf truescale.conf firewalld-sysctls.conf lockd.conf nvdimm-security.conf $monitor-sensor Waiting for iio-sensor-proxy to appear +++ iio-sensor-proxy appeared === Has accelerometer (orientation: normal) === No ambient light sensor === No proximity sensor As suggested by Bastien on https://bugzilla.kernel.org/show_bug.cgi?id=199715#c49 Magnetometer ----------- sudo iio_generic_buffer -A -N 0 iio device number being used is 0 iio trigger number being used is 0 Enabling all channels Enabling: in_magn_z_en Enabling: in_magn_y_en Enabling: in_magn_x_en /sys/bus/iio/devices/iio:device0 magn_3d-dev0 5.244241 8.323072 8.388735 5.244241 8.323072 8.388735 0.000050 -0.000070 -0.000053 Disabling: in_magn_z_en Disabling: in_magn_y_en Disabling: in_magn_x_en Accelerometer ------------- sudo iio_generic_buffer -A -N 1 iio device number being used is 1 iio trigger number being used is 1 Enabling all channels Enabling: in_accel_x_en Enabling: in_accel_z_en Enabling: in_timestamp_en Enabling: in_accel_y_en /sys/bus/iio/devices/iio:device1 accel_3d-dev1 514284.375000 816214.562500 816227.125000 1611713164867345890 514284.375000 816214.562500 816227.125000 1611713164867361519 0.000000 -0.882599 -0.196133 1611713165063435914 0.000000 -0.980665 -0.196133 1611713165271443260 Disabling: in_accel_x_en Disabling: in_accel_z_en Disabling: in_timestamp_en Disabling: in_accel_y_en Both ambient-sensor light and gyroscope are disabled as seen below sudo iio_generic_buffer -A -N 2 iio device number being used is 2 Failed to read name of device 2 sudo iio_generic_buffer -A -N 3 iio device number being used is 3 ls /sys/bus/iio/devices/ iio:device0 iio:device1 trigger0 trigger1 GNOME Shell finally has auto-rotate button available on system submenu. Auto-rotate finally works with some caveats: - The screen turned dark on each rotation before showing the desktop instead of a smoother transition. - Sometime the auto-rotation ramdomly crashes forcing a reboot. - On Settings-> Display, an option for screen rotation is missing. - On resume, screen rotation no longer works sudo evemu-record [sudo] password for luya: Available devices: /dev/input/event0: Power Button /dev/input/event1: Lid Switch /dev/input/event2: Power Button /dev/input/event3: AT Translated Set 2 keyboard /dev/input/event4: SynPS/2 Synaptics TouchPad /dev/input/event5: Video Bus /dev/input/event6: ELAN0732:00 04F3:264C /dev/input/event7: ELAN0732:00 04F3:264C UNKNOWN /dev/input/event8: ELAN0732:00 04F3:264C UNKNOWN /dev/input/event9: ELAN0732:00 04F3:264C /dev/input/event10: HP Wireless hotkeys /dev/input/event11: HP WMI hotkeys /dev/input/event12: HP Wide Vision FHD Camera: HP W /dev/input/event13: HP Wide Vision FHD Camera: HP I /dev/input/event14: HD-Audio Generic HDMI/DP,pcm=3 /dev/input/event15: HD-Audio Generic Mic /dev/input/event16: HD-Audio Generic Headphone Select the device event number [0-16]: 11 # EVEMU 1.3 # Kernel: 5.11.0-0.rc5.134.bz1651886_3.fc34.x86_64 # DMI: dmi:bvnAMI:bvrF.47:bd07/03/2020:br15.47:efr92.48:svnHP:pnHPENVYx360Convertible15-cp0xxx:pvr:rvnHP:rn8497:rvr92.48:cvnHP:ct31:cvrChassisVersion: # Input device name: "HP WMI hotkeys" # Input device ID: bus 0x19 vendor 0000 product 0000 version 0000 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event code 15 (SYN_MAX) # Event type 1 (EV_KEY) # Event code 138 (KEY_HELP) # Event code 141 (KEY_SETUP) # Event code 148 (KEY_PROG1) # Event code 153 (KEY_ROTATE_DISPLAY) # Event code 224 (KEY_BRIGHTNESSDOWN) # Event code 225 (KEY_BRIGHTNESSUP) # Event code 226 (KEY_MEDIA) # Event code 240 (KEY_UNKNOWN) # Event code 358 (KEY_INFO) # Event type 4 (EV_MSC) # Event code 4 (MSC_SCAN) # Event type 5 (EV_SW) # Event code 5 (SW_DOCK) # State 0 # Properties: N: HP WMI hotkeys I: 0019 0000 0000 0000 P: 00 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 24 10 02 00 00 00 00 B: 01 00 00 00 00 07 00 01 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 40 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 00 00 00 00 00 00 00 00 B: 04 10 00 00 00 00 00 00 00 B: 05 20 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 ################################ # Waiting for events # ################################ Note that SW_TABLET_MODE is missing from comment #44 preventing locking the keyboard when the laptop is folded in tablet mode. Overall, the patches fixed the auto-rotation part but needs refinements due to the mentioned caveats. Tested with amd_sfh.sensor_mask=5 parameter returned the same result.
@hdegoede Will it be able to push the patch upstream as bug fix? After several weeks on running the provided patched kernel, both accelerometer and magnetometer are running fine without hiccup on GNOME Shell session.
There was some upstream review-discussion about my patches fixing this. The discussion has been resolved now, so the patches will hopfully get merged upstream soon. Once they are merged upstream they can be backported to the Fedora kernels.
Cool! Let know about the version release.Thanks/
I recently upgraded to Fedora 34 Prerelease. The screen rotation broke on the new GNOME Shell 40 beta session at this time of writing while running on the provided patched kernel on #comment 48. As a result, the screen rotation button went missing. The sensor remained functional as tested: monitor-sensor Waiting for iio-sensor-proxy to appear +++ iio-sensor-proxy appeared === Has accelerometer (orientation: normal) === No ambient light sensor === No proximity sensor Accelerometer orientation changed: right-up Accelerometer orientation changed: normal
(In reply to Luya Tshimbalanga from comment #53) > I recently upgraded to Fedora 34 Prerelease. The screen rotation broke on > the new GNOME Shell 40 beta session at this time of writing while running on > the provided patched kernel on #comment 48. As a result, the screen rotation > button went missing. This seems like a mutter issue / regression to me, can you please file an issue with mutter upstream for this ? : https://gitlab.gnome.org/GNOME/mutter/-/issues/
(In reply to Hans de Goede from comment #54) > (In reply to Luya Tshimbalanga from comment #53) > > I recently upgraded to Fedora 34 Prerelease. The screen rotation broke on > > the new GNOME Shell 40 beta session at this time of writing while running on > > the provided patched kernel on #comment 48. As a result, the screen rotation > > button went missing. > > This seems like a mutter issue / regression to me, can you please file an > issue with mutter upstream for this ? : > > https://gitlab.gnome.org/GNOME/mutter/-/issues/ Done. https://gitlab.gnome.org/GNOME/mutter/-/issues/1686
Follow up about the regression, the screen rotation works on GNOME Xorg session. It turned out the issue mainly affects GNOME Wayland and I am unsure how to provide the log. I updated the ticket on upstream Mutter.
@hdegoede Any idea on which kernel version the fix related to better support of AMD Sensor Fusion Hub landed? I am currently running on the patched kernel you provided.
The patches for this have been merged by the HID maintainer here: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-5.12/upstream-fixes As the name of the branch indicates these should end up in 5.12. And CONFIG_AMD_SFH_HID=m is already set for the 5.12 Fedora kernel builds. So once Fedora builds a new 5.12-rc* kernel after that branch has been pulled in by Linus, then that and later Fedora kernels should work (and this bug can be closed). Note the patch to disable the non-working tablet-mode reporting has been merged for a while now.
Thank you for the update. I will test the incoming 5.12-rc* once available and am grateful for your help solving the issue.
Testing kernel 5.12.2-300.fc34.x86_64 confirmed the AMD Sensor Fusion HUB properly works as intended. The screen rotation works on GNOME Xorg while failing on GNOME Wayland due to upstream mutter issue highlighted on https://bugzilla.redhat.com/show_bug.cgi?id=1958433. The result from monitor-sensor Waiting for iio-sensor-proxy to appear +++ iio-sensor-proxy appeared === Has accelerometer (orientation: normal) === No ambient light sensor === No proximity sensor Accelerometer orientation changed: right-up Accelerometer orientation changed: normal Accelerometer orientation changed: left-up Accelerometer orientation changed: normal Magnetometer ------------ sudo iio_generic_buffer -A -N 1 iio device number being used is 1 iio trigger number being used is 1 Enabling all channels Enabling: in_magn_z_en Enabling: in_magn_y_en Enabling: in_magn_x_en /sys/bus/iio/devices/iio:device1 magn_3d-dev1 5.244241 8.323072 8.388735 5.244241 8.323072 8.388735 0.000048 -0.000071 -0.000059 Disabling: in_magn_z_en Disabling: in_magn_y_en Disabling: in_magn_x_en Accelerometer ------------- sudo iio_generic_buffer -A -N 0 iio device number being used is 0 iio trigger number being used is 0 Enabling all channels Enabling: in_accel_x_en Enabling: in_accel_z_en Enabling: in_timestamp_en Enabling: in_accel_y_en /sys/bus/iio/devices/iio:device0 accel_3d-dev0 514284.375000 816214.562500 816227.125000 1620434005107038424 514284.375000 816214.562500 816227.125000 1620434005107050116 0.000000 -0.882599 -0.392266 1620434005164378012 0.000000 -0.882599 -0.392266 1620434005372668079 Disabling: in_accel_x_en Disabling: in_accel_z_en Disabling: in_timestamp_en Disabling: in_accel_y_en A small issue is related to resume but we can open a separate ticket upstream. The main goal to support the sensor has been reached.
Luya, thanks for all your testing and for confirming that this is fixed, lets close this then.