[systemd-devel] Bad accelerometer values cause incorrect screen rotation

[Dave Howorth]

On Thu, 5 Sep 2019 17:05:11 +0800
Daniel Drake <drake at endlessm.com> wrote:
> Hi,
> 
> Over the years we've seen a bunch of reports of systems that
> automatically rotate the display to some incorrect orientation, based
> on trusting some accelerometer data values which were not interpreted
> correctly. I have another affected system in hand here.
> 
> When this unfortunate situation happens, the user experience is really
> terrible. Except for workarounds that involve going to the command
> line, the best workaround under GNOME seems to be to physically rotate
> the device into a position that causes the screen orientation to be
> normal/unrotated, then while maintaining and holding the device in
> that highly awkward position with one hand, try your very best to
> manipulate the mouse cursor with your other hand and navigate the menu
> to enable Orientation Lock.
> 
> Since the effects of this issue when it bites are so bad, and because
> it seems like we aren't winning the "quirk the accelerometer" game
> here, I'm wondering if it's time for us to restrict this default
> setting of automatic rotation based on accelerometer data to only
> situations where:
>  1. The product is actually designed to be usable when rotated, and
>  2. We have a higher degree of confidence that we're actually
> interpreting the accelerometer data correctly
> 
> 
> Why are we not winning? Why can't we fix this properly?
> 
> I think we're suffering largely through applying this auto-rotation
> behaviour to all accelerometer data, from setups where previously
> nobody really cared if the data was misinterpreted, or the data was
> specifically interpreted for a different context (we're specifically
> interested in measuring the physical orientation of the screen, but
> accelerometers have other uses too).
> 
> Windows 10 (and presumably 8) does have the automatic screen rotation
> feature based on accelerometer data, but it seems to apply to fewer
> products. For example it does not apply automatic rotation to the
> Quanta NL3 classmate nor to the HP EliteBook 840 G3, two systems that
> I have in hand that both required specific engineering on Linux after
> real users had already run into the horrible
> automatic-incorrect-rotation described above:
> https://github.com/systemd/systemd/commit/ebf482e7cdabfc1266a86ec8a5f92a964ce08afe
> hp_accel: fix accelerometer orientation for EliteBook 840 (patch
> posted today, no link yet)
> 
> The challenge here is a lack of standardization of how accelerometers
> are installed relative to the screen, and a lack of a standard way of
> accessing model-specific data that gives us this info. Without any
> better options we've been trying to create and maintain our own
> databases, for example systemds 60-sensor.hwdb and Linux kernel's
> hp_accel.c, but that's turning out to be problematic because:
>  1. The databases entries are mostly created retroactively - usually,
> entries are created when a tech-savvy user steps forward to share the
> required data, after one or more users have already been bitten by the
> issue. This is sub-standard.
>  2. We estimate the right way to distinguish models for different
> quirks by hoping that DMI data will serve this purpose, but we also
> don't know how to do that reliably, so sometimes we even apply the
> wrong quirks. Two recent examples:
> https://bugzilla.redhat.com/show_bug.cgi?id=1717712 (more on this
> case below) hp_accel: fix accelerometer orientation for EliteBook 840
> (patch posted today, no link yet)
> 
> Bastien once made the suggestion that we could fish the model-to-quirk
> mapping from the Windows drivers, but I can't find anything in the HP
> driver. On HP EliteBook 840 the device is not even exposed as a sensor
> under Windows and I can't find any way of accessing the data or making
> it auto-rotate - maybe they don't even have such a mapping? The only
> Windows application of this sensor seems to be automatic hard disk
> head parking, which presumably just detects sudden movements in any
> direction.
> 
> We did recently work with some Acer all-in-one PCs which had an
> accelerometer which also provided working auto-rotation under windows
> out of the box, while again producing the wrong and awkward behaviour
> on Linux. Thanks to vendor contacts we did discover the scheme used,
> and now automatically detect the accelerometer orientation on such
> products.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f38ab20b749da84e3df1f8c9240ddc791b0d5983
> However, we then found DSDTs with this orientation data that far
> predated this patch's existence. So not a great win; our solution was
> not made in timely fashion.
> 
> ACPI offers something that might help - PLD can be used to describe
> the physical orientation of product components. But I don't think
> we've seen any examples of this data being provided by vendors for
> accelerometers.
> 
> I see the latest development of having the hwdb specify whether the
> accelerometer is in the base or the display of the device. This was
> implemented for dealing with a device with accelerometers in both
> positions (https://github.com/hadess/iio-sensor-proxy/pull/262) -
> clearly the screen rotation should only follow thy display-mounted
> accelerometer in that case.
> 
> However now that iio-sensor-proxy ignores "base" accelerometers
> (regardless of whether or not there's another accelerometer in the
> display), that's being misused at least in this case:
> https://bugzilla.redhat.com/show_bug.cgi?id=1717712
> This is a HP laptop and it looked like the policy was once "we will
> not accept quirks for HP machines that use the lis3lv02d device, they
> should go in the hp_accel.c driver instead"
> (https://github.com/systemd/systemd/commit/0d1a2be93e16aa03026f1c36e81951097e8dad2c)
> but that doesn't seem to have been followed here.
> Although in this case the quirk just states that the sensor is in the
> base of the laptop, which now causes iio-sensor-proxy to ignore it.
> But since the kernel data was wrong in the first place, the user is
> now left with an accelerometer that can't be used to play neverball,
> nor can be used to rotate the screen.
> In the single accelerometer case, for an ordinary clamshell laptop, it
> doesn't actually matter if the accelerometer is in the display or not.
> Since the accelerometer measures all 3 dimensions and screen position
> relative to the base is known, a mount matrix can be applied to deal
> with any positioning scheme.
> What if we had an ordinary clamshell laptop producing "bad" data where
> the accelerometer is actually mounted behind the display (was this
> even checked here?) - would a ACCEL_POSITION=base quirk still then be
> accepted?
> 
> Although this fix seems somewhat technically incorrect, perhaps it has
> its roots in the same things I'm trying to say here: when the bug
> bites it's really quite serious, it's tricky and annoying to fix the
> root cause, and why do we even care about automatic screen rotation on
> standard clamshell laptops anyway - the product itself is totally
> unusable when in any position other than "sitting flat on the desk" -
> just try typing or using the touchpad...
> 
> 
> How can we improve?
> 
> Ideally I think we should disable the automatic rotation on all
> devices except for:
>  - Laptops that have detachable screens (effectively converting them
> into a tablet) with the accelerometer mounted to the screen
>  - Convertible laptops where the screen can be physically rotated
> around and folded down to sit on top of the keyboard, with the
> accelerometer mounted to the screen
> - All in One PCs
> - Tablets
> - Smartphones
> 
> By nature of not automatically rotating on ordinary clamshell laptops,
> that would actually solve 100% of the cases that I've come across.
> 
> But maybe we're then left with similar "how can we detect the
> mount-matrix" problems on the remaining device classes (I'm especially
> unfamiliar with tablets and smartphones).
> 
> And detecting the different device classes is also not trivial. DMI
> and ACPI don't offer precisely what we need here, and vendors aren't
> especially consistent there anyway.
> 
> The best proposal I can think of is to disable automatic rotation on
> all devices, except for systems that pass two tests:
> 
> 1. The DMI chassis type is All In One or HandHeld, or the ACPI power
> profile is tablet (hostnamectl already reads this - perhaps it has
> some degree of reliability?), or the model is on a "this
> accelerometer-equipped device can sensibly be used in different
> physical orientations" hwdb whitelist
> 
> and:
> 
> 2. The kernel exports a mount matrix, or there is a mount matrix in
> the hwdb (the identity matrix can be used to create further whitelist
> entries). If we have multiple accelerometers, require a hwdb whitelist
> to determine which one is display-mounted.
> 
> Also leaving some room for a potential future UI control to override
> this (and calibrate too?).
> 
> End of brainstorm... Any thoughts?

Don't know anything about the issues but ...

I'd agree with your assessment to make it fail safe to a fixed
orientation unless the system is absolutely sure about the properties
of the environment it is in.

Why not allow enablement under user control? e.g. User selects
'Orientation Set Up' or some such, system presents instructions for user
to orient screen in appropriate way for current screen display, then
changes display to some other orientation and requests user to orient
accordingly. Rinse and repeat until sufficient data is obtained and
then enable the automatic orientation option.

> Thanks,
> Daniel
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel