IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit 1bd5db86f5.
The `kxcjk-1013` driver in Linux will parse the rotation matrix
from ACPI. This quirk is not specific enough to exist without
causing issues on different variations.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
- Breaks AYANEO AIR family into different entries as not all are mounted the same.
- Corrects AYANEO AIR mount matrix.
- Adds mount matrices for AYANEO device families: 2021, AYANEO 2, AYANEO GEEK, and AYANEO FLIP
- Adds mount matrix for GPD WinMax2
- Adds mount matrix for OrangePi NEO
This update has been tested on the 2023 Chuwi Freebook N100. The hwdb entry has been verified using these commands:
cat /sys/`udevadm info -q path -n /dev/iio:device0`/../modalias
acpi:MDA6655:MDA6655:
cat /sys/class/dmi/id/modalias
dmi:bvnAmericanMegatrendsInternational,LLC.:bvrDNN20AV1.03:bd12/29/2023:br1.3:efr0.7:svnCHUWIInnovationAndTechnology(ShenZhen)co.,Ltd:pnFreeBook:pvrDefaultstring:rvnDefaultstring:rnDefaultstring:rvrDefaultstring:cvnDefaultstring:ct10:cvrDefaultstring:skuDefaultstring:
The correct offset orientation has been tested with:
monitor-sensor
Waiting for iio-sensor-proxy to appear
+++ iio-sensor-proxy appeared
=== Has accelerometer (orientation: normal)
=== No ambient light sensor
=== No proximity sensor
Original info:
acpi:KIOX000A:KIOX000A:
dmi:bvnTECLAST:bvrG4K3_A1tPAD3.01:bd08/25/2017:br5.12:efr14.4:svnTECLAST:pnX3Plus:pvrDefaultstring:rvnTECLAST:rnX3Plus:rvrDefaultstring:cvnDefaultstring:ct30:cvrDefaultstring:skuG4K3_A1:
It seems that teclast x3 plus has another sku G4K2. Not owning that sku, I decide not to cover the change on G4K2.
There is a later model version of the Chuwi Hi10X that has significantly changed components compared to the existing hwdb one. Differentiator (on Chuwi forums, in thesofproject, etc.) is the N4120 rather than the N4100 processor.
The svn and pn seem to be identical, my Chuwi Hi10X matches with the old model except for the changed KIOX000A* iio sensor.
With the added ACCEL_MOUNT_MATRIX, my device works on gnome and has the correct (right-up) output in monitor-sensors.
The [kernel documentation][0] for the in_proximity_nearlevel sysfs
attribute on iio proximity devices states:
If the value read from the sensor is above or equal to the value in
this file an object should typically be considered near.
Meaning a 'greater than or equal to' comparison.
Make the documentation comment in 60-sensors.hwdb suggest a
greater-or-equal rather than a strict greater-than comparison.
[0]: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iio-proximityFixes#25793
The base-mounted accelerometer on Chromebooks return values same as the
display when the lid angle is 180 degrees, instead of when the lid is
closed. To match userspace expectations we must further rotate the
existing accelerometer mounting matrix by 180 degrees around the X axis:
[[-1, 0, 0], [[ 1, 0, 0], [[-1, 0, 0],
[ 0, -1, 0], X [ 0, -1, 0], = [ 0, 1, 0],
[ 0, 0, -1]] [ 0, 0, -1]] [ 0, 0, 1]]
A previous commit lets us distinguish between the two cros-ec-accel
devices on these boards by their 'label' sysfs file. Add hwdb entries
that make base-mounted accelerometers use this correct matrix, and
display-mounted ones use the existing one.
Note that the cros-ec-accel drivers use 'label' only since Linux v6.0.
The old match strings are not removed to support older kernels, even
though they are only correct for the display-mounted sensor.
The IIO subsystem exposes a 'label' sysfs file to help userspace better
identify its devices [1]. Standardized labels include the sensor type
along with its location, including 'accel-base' and 'accel-display'.
Most Chrome OS boards have two accelerometers that are indistinguishable
except for this label (or a 'location' sysfs file before Linux v6.0),
and need different mounting matrix corrections based on their location.
Add a udev rule that matches hwdb entries using this label, so we can
correct both accelerometers on these devices with hwdb entries. The
existing rules and hwdb entries are not modified to keep potential
out-of-tree entries working, but new entries in this form will override
existing ones. Also add currently standardized labels to parse-hwdb.py.
[1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iio