The Lenovo ThinkPad Yoga 11e 360 degree hinges style 2-in-1s use 2
accelerometers, 1 in the display and 1 in the base.
Kernel work is under way to also export the second accelerometer in
the base as an iio-device; and userspace work is underway to use
both accelerometers on 360 degree hinges style 2-in-1s (with 2 accels)
to figure out the angle between the 2 halves.
So far most orientation-matrix quirks have not cared much about the
Z-axis being correct, but in these 2 accelerometer setups getting
the Z-axis correct is important too.
The KIOX010A and KIOX02A ACPI hw-ids (HIDs) are used in 360 degree hinges
style 2-in-1s which have 2 accelerometers, 1 in the display (as usual) and
a second accelerometer in the base.
So far 60-sensor.hwdb has only defined a mount-matrix for the
sensor with the KIOX010A HID, which is the sensor in the display
half of the device. The reason for this is that sofar userspace has
only cared actually used the sensor in the display (for automatic
display rotation. Work is underway to make userspace use both sensors:
https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/216
Recently an entry was added for the Medion Akoya's E2221T base-sensor,
but that was added to mark it with ACCEL_LOCATION=base and the entry
simply used the identity-matrix for ACCEL_MOUNT_MATRIX since nothing
is using the mount-matrix info for the second accelerometer.
I believe that this entry was added because on some devices the second
accelerometer gets enumerated first and then iio-sensor-proxy will
wrongly use the second sensor for display-rotation, unless it is marked
with ACCEL_LOCATION=base.
Instead of adding info for the second accelerometer on a per device
basis use the same generic dmi matches as used for the first (KIOX010A)
sensor, replacing the special case added for the E2221T and also
update the ACCEL_MOUNT_MATRIX with the actual mount-matrix for the
KIOX020A sensor in the base of these devices.
This was tested on a Medion Akoya E2228T.
Document how the mount-matrix for the base-accelerometer must be set on
360 degree hinges style 2-in-1s with 2 sensors (one in the display and
1 in the base).
Note the choice to define the lid being fully closed as an angle of
0 degrees is based on the ACPI tables of devices with a BOSC0200
ACPI device-node describing both sensors. In this case the ACPI
tables contain mount-matrix info (and the kernel will soon support
reading this and exporting it to userspace) and the mount-matrices
defined in these ACPI tables are such that the angle of the G-force
vector measured by the sensors is identical for both sensors when
the laptop's lid is fully closed.
This also feels more natural then defining the laptop being fully
open (180 degrees open) as the home / 0 degree angle position.
In Fedora rawhide various perl modules are now available as separate
packages that are not pulled in by dependencies. If we don't have some
package, skip the tests.
This ugly code is apparently the way to do conditional imports:
https://www.cs.ait.ac.th/~on/O/oreilly/perl/cookbook/ch12_03.htm.
This reverts commit 34136e1503.
Having the "%H" host name specifier in a DNSSD service name template
triggers a failed assertion during name template instantiation as
specifier_dnssd_host_name expects DnssdService in its userdata
pointer but finds NULL instead.
In NEWS, the new option was described twice, most likely because the first
description was tucked away in a paragraph about some other subject.
While at it, improve the descriptions in the man page to make it easier to grok
what that option really does.
test_oomd_cgroup_context_acquire_and_insert reads the live cgroup data used
by the unit test. Under certain conditions, the memory pressure for the cgroup
can be non-zero (although most of the time it is 0 since these tests don't
generate much pressure).
Since these values are too dependent on the state of the system, remove the
checks. The type used is always >= 0 and test-psi-util already unit tests that
PSI values are parsed correctly from files so this test is redundant anyways.
Follow-up for ac24e418d9.
The original motivation of the commit and RFE #15339 is to start dhcpv6
client in managed mode when neither M nor O flag is set in the RA.
But, previously, if the setting is set to "always", then the DHCPv6
client is always started in managed mode even if O flag is set in the
RA. Such the behavior breaks RFC 7084.