iio-sensor-proxy says: "Could not find any supported sensors" on Dell XPS 15 9575 2-in-1 on Cosmic 18.10

[Mario Vukelic]

On Cosmic, iio-sensor-proxy 2.4, with default 4.18 kernel as well as latest mainline 4.19.0-041900rc3-generic.

There is no rotation lock button in the gnome-shell panel menu.
Gnome Settings > Device Display shows rotation buttons
There is no directory /sys/bus/iio

Reproduction:
1. Rotate device, fold display back to tent and tablet modes:

-> Rotation is not detected. When folding to tablet mode, device goes to suspend as if display had been closed normally.

iio-sensor-proxy finds no sensors:
~$ systemctl status iio-sensor-proxy.service
● iio-sensor-proxy.service - IIO Sensor Proxy service
Loaded: loaded (/lib/systemd/system/iio-sensor-proxy.service; static; vendor preset: enabled)
Active: inactive (dead)

I reported issue as https://github.com/hadess/iio-sensor-proxy/issues/236 and was advised:

"Looks like there's no supported sensors, or just no sensors inside this machine. Nothing that we can do about it, except asking your vendor for support (eg. is there one or multiple sensors, and if so, why aren't they supported in the kernel)"

I posted the issue in Dell's Project Sputnik's Google+ community

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: linux-image-4.18.0-7-generic 4.18.0-7.8
ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
Uname: Linux 4.18.0-7-generic x86_64
ApportVersion: 2.20.10-0ubuntu9
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: mario 2139 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Sun Sep 16 20:20:48 2018
InstallationDate: Installed on 2018-09-13 (2 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Alpha amd64 (20180912)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 0489:e0a2 Foxconn / Hon Hai
 Bus 001 Device 004: ID 27c6:5395
 Bus 001 Device 002: ID 0bda:58f4 Realtek Semiconductor Corp.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Dell Inc. XPS 15 9575
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-7-generic root=UUID=26ff4c95-5f68-4121-b7d0-989fa705fcc8 ro quiet splash pcie_aspm=force drm.vblankoffdelay=1 i915.fastboot=1 vt.handoff=1
RelatedPackageVersions:
 linux-restricted-modules-4.18.0-7-generic N/A
 linux-backports-modules-4.18.0-7-generic N/A
 linux-firmware 1.175
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/08/2018
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.1.9
dmi.board.name: 0C32VW
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.1.9:bd08/08/2018:svnDellInc.:pnXPS159575:pvr:rvnDellInc.:rn0C32VW:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.family: XPS
dmi.product.name: XPS 15 9575
dmi.product.sku: 080D
dmi.sys.vendor: Dell Inc.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Mario Vukelic (kreuzsakra)]

I forgot to add that
1: Secure boot is off
2. When testing with mainline kernel I also removed the pcie_aspm=force, drm.vblankoffdelay=1, and i915.fastboot=1 boot parameters. No difference

[Mario Vukelic (kreuzsakra)]

Fixed in latest mainline kernel v4.19-rc4. Please let me know if you need any additional info

~$ uname -r
4.19.0-041900rc3-generic

~$ ls /sys/bus/iio/
devices drivers drivers_autoprobe drivers_probe uevent

~$ systemctl status iio-sensor-proxy.service
● iio-sensor-proxy.service - IIO Sensor Proxy service
   Loaded: loaded (/lib/systemd/system/iio-sensor-proxy.service; static; vendor
   Active: active (running) since Tue 2018-09-18 22:21:24 CEST; 6min ago
 Main PID: 877 (iio-sensor-prox)
    Tasks: 3 (limit: 4915)
   Memory: 2.1M
   CGroup: /system.slice/iio-sensor-proxy.service
           └─877 /usr/sbin/iio-sensor-proxy

[Joseph Salisbury (jsalisbury)]

Just to confirm, you see this bug in v4.19-rc3, but not in v4.19-rc4?

There were only 3 iio specific commits added in v4.19-rc4, and none stick out as being the fix, but it could have come from a non-iio specific commit.

eca743dc37e1 Merge tag 'iio-fixes-4.19a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
a13bf65f3f2e iio: imu: st_lsm6dsx: take into account ts samples in wm configuration
65099ea85e88 Revert "iio: temperature: maxim_thermocouple: add MAX31856 part"

[Mario Vukelic (kreuzsakra)]

> Just to confirm, you see this bug in v4.19-rc3, but not in v4.19-rc4?

Yes. I have both rc3 and rc4 installed. Booting into rc3 rotation does not work, booting into rc4 it works, I just reconfirmed it once more.

[Mario Vukelic (kreuzsakra)]

And sorry, the uname result I copied into comment #4 was wrong. It should have been of course:

uname -r
4.19.0-041900rc4-generic

And this ^ is from just now. (In comment #4 my clipboard content was wrong)

[Mario Vukelic (kreuzsakra)]

Update after playing with this a bit:

While the sensors are detected by the mainline rc4 (and rc5) kernel as stated above, the rotation does not work correctly. I am not sure if this is still a kernel issue or happens elsewhere. Would be great if you could point me in the right direction.

According to the output of the monitor-sensor command of iio-proxy-sensor, it detects the correct orientation in all attempts. However, in some scenarios something rotates the screen back to normal automatically and immediately. When this happens, monitor-sensor does NOT output a switch to "normal". So I suppose the sensor outputs remain correctly detected and the switching back happens elsewhere.

On the other hand, this may be connected to a hardware quirk in how the rotation is implemented on the Dell XPS, which similarly also occurs in Windows (https://www.dell.com/community/XPS/Dell-XPS-13-9365-Rotation-lock-unavailable-grayed-out-EXPLAINED/td-p/6075400):
* Laptop mode, i.e. keyboard-to-screen angle BELOW 90 degrees: In Windows, this automatically engages the rotation lock, i.e. the screen does not rotate at all.
* Tent/tablet mode, i.e. keyboard-to-screen angle ABOVE 90 degrees: In Windows, this releases the rotation lock automatically.

The behavior I see in Ubuntu also depends on the keyboard-screen angle. However, the rotation lock in the Gnome panel does NOT automatically engage if the angle is below 90 degrees.
This is what happens:

* Angle BELOW 90:
- Orientation "left-up": screen rotates to portrait correctly, but immediately switches back to normal.
- Orientation "right-up": screen rotates to portrait correctly and in most attempts stays like this, but occasionally it immediately switches back to normal.
- Orientation "bottom-up": screen rotates rotates upside-down correctly, but immediately switches back to normal.
- Orientation "normal": screen always rotates back correctly (if it didn't automatically switch back anyway).

* Angle ABOVE 90:
- Orientation "left-up": screen rotates to portrait correctly and in most attempts stays like this, but occasionally it immediately switches back to normal.
- Orientation "right-up": screen rotates to portrait correctly and apparently randomly either stays like this or immediately switches back to normal.
- Orientation "bottom-up": screen rotates rotates upside down correctly most of the time (but occasionally doesn't).
- Orientation "normal": screen always rotates back correctly (if it didn't automatically switch back anyway).

As you can see, the "left-up" and "right-up" behaviors seem somewhat (but not entirely) swapped depending on the keyboard-screen angle.

[Joe Barnett (thejoe)]

fwiw, bug 1797174 captures the behavior from @mario-vukelic's comment

[Mario Vukelic (kreuzsakra)]

Thanks, Joe. And urgh, whenever I wrote 90 degrees in the previous comment I meant 180. I copied the fixed description to the other bug.

By the way, the other bug says that this enables the sensors on kernel 4.18 as well:

modprobe intel-ish-ipc
echo "8086 a135" > /sys/bus/pci/drivers/intel_ish_ipc/new_id

[Mario Vukelic (kreuzsakra)]

This seems to be the kernel bug report for the missing sensors:
https://bugzilla.kernel.org/show_bug.cgi?id=200655
and the patch mentioned there: https://lore.kernel.org/patchwork/patch/975429/

Kernel bug status is resolved. Last comment from 2018-09-10 says that it would be merged in 4.10, but apparently this happened in 4.19-rc4 (see my above comments)

[Mario Vukelic (kreuzsakra)]

"... would be merged in 4.20" (not 4.10) of course

[Your full name (wzpdqbty)]

LP: #1807250

Xenials kernel 4.4.0-134, debian stable kernel 4.9.8, debian testing kernel 4.18.20 are all working when booted with bionic userspace. According to nacc upcoming cosmic 4.18 is also affected.

[Kai-Heng Feng (kaihengfeng)]

The fix lands since Ubuntu-4.18.0-12.13.