Inverted laptop screen for HP Envy 15-as006nf

[Forage]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

231

Used distribution

Ubuntu 16.10 GNOME

As discussed in an iio-sensor-proxy issue, I need to adjust the systemd configuration to fix my laptop screen from being inverted, with the screen upside down and the mouse pointer movement mirrored.
A rotation lock button is also added to the bottom of the main menu (GNOME Shell 3.22) at the top left, between the settings and session lock button. My laptop has no option to rotate the screen though.

Apparently I should be adding the laptop to https://github.com/systemd/systemd/blob/master/hwdb/60-sensor.hwdb but I do not know how to determine the required information.
How do I determine the parent device modalias, dmi string and the required matrix itself?

Let me know if you need any more information.

[poettering]

@hadess can you help?

[hadess]

How do I determine the parent device modalias, dmi string and the required matrix itself?

Please attach the output of udevadm info --export-db on that system. You'll need to figure out the matrix yourself, but you can use test-orientation-gtk in iio-sensor-proxy to test the different options.

[Forage]

Thank you for your reply. Attached is the output of udevadm.

udevadm.txt

[hadess]

This is probably the same bug as: hadess/iio-sensor-proxy#111

Looks like all HP devices would need a quirk as the driver itself sends the incorrect data (it assumes the accelerometer is in the keyboard and gives data for that orientation).

The match rule could be:

sensor:modalias:platform:lis3lv02d:dmi:*

CC: @phomes

[Forage]

#########################################
# HP Envy 15-as006nf
#########################################
sensor:modalias:platform:lis3lv02d:dmi:*
#ACCEL_MOUNT_MATRIX=1, 0, 0; 0, 0, -1; 0, 1, 0
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1

Is what I've added to /etc/udev/hwdb.d/61-sensor-local.hwdb, after which I executed sudo systemd-hwdb update and rebooted my system. Both MATRIXs result in the desired effect: mouse movement and screen orientation is normal again.

Since both just work and the 'rotation lock button' disappears in either case, I get the feeling that something else got broken because of it, instead of things actually being fixed. I have no clue how the matrix is working though, so it might just as well be normal in both cases.

[Forage]

Yeah, I can confirm now that things are simply unstable. In what appears to be random, after one reboot the problems are back, after another reboot the problems are gone. No matter which matrix.

The syslog tells me Failed to start IIO Sensor Proxy service.
syslog.txt

What more can I provide you to narrow down this issue?

[hadess]

Yeah, I can confirm now that things are simply unstable. In what appears to be random, after one reboot the problems are back, after another reboot the problems are gone. No matter which matrix.

That's probably because of the long-standing bug in the IIO (or HID, or ACPI) subsystem which makes IIO triggers not work, so your accelerometer never gets any updates. When it shows up "the right way", it's likely that iio-sensor-proxy can't actually read anything from the device. Usually, suspending and resuming the machine should fix it.

The syslog tells me Failed to start IIO Sensor Proxy service.
Feb 3 09:13:34 ABO-HP iio-sensor-proxy[1101]: ERROR:iio-sensor-proxy.c:185:send_dbus_event: assertion failed: (data->connection)

That's bad, and I don't know how it would happen. Can you please file an issue against iio-sensor-proxy about this?

systemctl reset-failed iio-sensor-proxy.service should restore the daemon for the next boot.

[hadess]

Filed it, see link above.

[Forage]

Installing iio-sensor-proxy 2.2 fixes the instability issue. At the same time, however, there are no longer inverted screen issues to begin with. With or without any of the matrices above, the screen functions properly either way. I'm happy with the result, but it also makes me wonder why the settings appear to be ignored. I double checked the match rule and it appears to be correct. Is there a way I can check if/why the matrix settings are being ignored?

[phomes]

Yes, seems like the same problem I have with mine. I never managed to find a good way to match mine.

Using this does not work for me:

sensor:modalias:platform:lis3lv02d:dmi:*
#ACCEL_MOUNT_MATRIX=1, 0, 0; 0, 0, -1; 0, 1, 0
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1

This is what I get
looking at device '/devices/platform/lis3lv02d/input/input13/event7':
KERNEL=="event7"
SUBSYSTEM=="input"
DRIVER==""

looking at parent device '/devices/platform/lis3lv02d/input/input13':
KERNELS=="input13"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{max}=="2000"
ATTRS{min}=="0"
ATTRS{name}=="ST LIS3LV02DL Accelerometer"
ATTRS{phys}=="lis3lv02d/input0"
ATTRS{poll}=="50"
ATTRS{properties}=="0"
ATTRS{uniq}==""

looking at parent device '/devices/platform/lis3lv02d':
KERNELS=="lis3lv02d"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"
ATTRS{position}=="(54,144,1080)"
ATTRS{rate}=="100"
ATTRS{selftest}=="OK -31 32 36"

looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""

[phomes]

With this in rules it does work though:

SUBSYSTEM=="input", ENV{ID_INPUT_ACCELEROMETER}=="1", SUBSYSTEMS=="platform", \
  IMPORT{builtin}="hwdb 'sensor:modalias:$attr{modalias}:$attr{[dmi/id]modalias}'", \
  GOTO="sensor_end"

[phomes]

(edit: point to branch instead. Contains typo fix)
As branch here:
https://github.com/phomes/systemd/commits/accel-hwdb

Rules change inspired by #5471

[dsd]

That rule probably will suffer from an issue we faced in #5471. We want the mount matrix applied to both event7 and input13 but your rule will only apply it to event7. (check with udevadm info -e)

To follow #5471 you can make the rule reconstruct the modalias for the platform bus when querying hwdb. Looking at platform.c:modalias_show the modalias for a platform device is built with this logic:

1. Get it from OF. (not really sure how to handle this in rules, could be out of scope here?)
2. Otherwise get it from ACPI. (on my system, devices that get a name from here have SUBSYSTEM=acpi so would not be matched by this rule)
3. Otherwise use format platform:devicename

In this case we'll need the device name of the matched parent which I think we can get with $id ? So the rule would be:

SUBSYSTEM=="input", ENV{ID_INPUT_ACCELEROMETER}=="1", SUBSYSTEMS=="platform", \
  IMPORT{builtin}="hwdb 'sensor:modalias:platform:$id:$attr{[dmi/id]modalias}'", \
  GOTO="sensor_end"

[phomes]

Works perfectly with that rule. I had only checked that event7 and js0 got the mount matrix. Now input13 does as well. Thanks! I force pushed the updated version. I will open a separate PR for it as it is a different laptop model than the one in this issue.

[Forage]

I still cannot reproduce the issue after updating to iio-sensor-proxy 2.2, even with the rules above added to /etc/udev/rules.d/60-sensor.rules.
60-sensor.rules.txt

I would have expected to be able to force rotating my screen with one of the matrices added to /etc/udev/hwdb.d/61-sensor-local.hwdb but this is not the case.

I suppose this issue can be closed for me. I'll leave it up to you guys to close it though, since it might be of value for you to find out why it's not working. If so, I'll be happy to provide more info. If not, feel free to close the issue.

[phomes]

@Forage My guess is that by updating to iio-sensor-proxy 2.2 you also got this fix which would correct the orientation:
hadess/iio-sensor-proxy@35b6328

However, for the other HP laptops I have tested on a quirk is still needed. The orientation is not inverted but turning the laptop to the side would work ok, but turning it back to normal would not be detected. Instead I had to tilt the keyboard towards me to get the normal orientation again. That is what the patch in #5510 is for. Can you test if that patch is needed for this laptop model?

[hadess]

My guess is that all the laptops using this particular driver will need the quirks because, instead of being in the screen, as with more modern convertible laptops (be them Yogas or Surfaces), the accelerometer is quirked as if in the base, as mentioned in the documentation:

Known models (full list can be found in drivers/platform/x86/hp_accel.c) will have
their axis automatically oriented on standard way (eg: you can directly play neverball).

[hadess]

We discussed this with @dsd at GUADEC, and what came out of it was:

1. Try to see whether the _PLD ACPI bit would be interesting.
   See this mail and links out of that:
   http://marc.info/?l=linux-iio&m=147981183211362&w=2
2. If that doesn't pan out, see whether the Windows drivers contain .inf files with the quirks information already. The drivers download could then be automated if it contains interesting information.