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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
The cros-ec-accel and cros-ec-accel-legacy kernel modules internally
correct for the board-specific accelerometer mounting orientations.
Their sensor outputs are in a standard reference frame consistent across
different boards, so the orientation matrix already added for a number
of devices should apply to every device using cros-ec accelerometers.
The different matrix for the 'Nocturne' board seems to be an error.
Replace the existing hwdb rules for select Chromebooks with generic
rules that apply to all Chromebooks.
We've had this text since the beginning, but in fact the patterns must be
stable in order for people to create local hwdb entries. And we support that
and can't change the match patterns without being very careful. So let's just
drop the text.
Kernels >= 5.8 have added new fields to the dmi/id/modalias file in the
middle of the modalias (instead of adding them at the end).
Specifically new ":br<value>:" and (optional) ":efr<value>:" fields have
been added between the ":bd<value>:" and ":svn<value>:" fields.
Note the 5.13.0 and 5.14.0 kernels also added a new ":sku<value>:" field
between the ":pvr<value>:" and ":rvn<value>:" fields, this has been fixed
in later 5.13.y and 5.14.y releases, by moving the sku field to the end:
https://lore.kernel.org/lkml/20210831130508.14511-1-hdegoede@redhat.com/
Unfortunately the same cannot be done for the new br and efr fields since
those have been added more then a year ago and hwdb even already has some
newer entries relying on the new br field being there (and thus not working
with older kernels).
Fix the issue with the br and efr fields through the following changes:
1. Replace any matches on ":br<value>" from newer entries with an '*'
2. Replace "bd<value>:svn<value>" matches with: "bd<value>:*svn<value>"
inserting an '*' where newer kernels will have the new br + efr fields
This makes these matches working with old as well as new kernels.
Link: https://github.com/systemd/systemd/issues/20550
Link: https://github.com/systemd/systemd/pull/20562
This is a related commit to the bug reported in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1938259
This adds additional 4 models that without this param, the screen rotates
when the clamshell laptop rotates, which is an unwanted behavior.
This commit also merges entries that needs the same param.
Signed-off-by: Yao Wei (魏銘廷) <yao.wei@canonical.com>
This commit was done to add sensor rule for Hometech Wi101. Note that this rule might be too general and need fixes. I couldn't test this on any other device since this one is the only one I have.
Co-authored-by: Simeonlps <Simeonlps@users.noreply.github.com>
Signed-off-by: Wind/owZ <windowz414@gnuweeb.org>
Recently the kernel has gotten support for reading the mount-matrix for
BMA250 sensors represented by a BOSC0200 ACPI device from the ACPI tables,
so that we don't need to add quirks for these.
At least that was the theory. The Chuwi Hi13 (CWI534) with BMA250 sensor
has the sensor mounted such that it works / needs the normal(ized) matrix,
but the ACPI tables actually contain a wrong matrix inverting the X and Y
axis.
Add a quirk to override /sys/bus/iio/devices/iio:device?/in_mount_matrix
with the norm-matrix, since the ACPI derived matrix is actually wrong on
these devices (sigh)
We use pvr match for efifb pitch and drm orientation quirk and in touchpad toggle keymap. Also seems most consistent with the devices here.
While at it, correct a typo, 81H3 and 81MD are product names not numbers, my bad.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
D330-10IGM has been added due the fact that 81H3 and 81MD product name belongs to the same product version. So the fact is that now that we know 81MD has the same transformation matrix that the 81H3 we can just use the product version and get rid the product name.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
Added Cube Mix Plus (i18B) Rotation information.
Also Combined the sensor lines with the different Cube i7 stylus models because they use the same ACCEL_MOUNT_MATRIX
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.
No functional change is intended.
The general pattern of changes:
-usb:v04F3p2B7C*
+usb:v04F3p2B7C:*
This is mostly a clarification, to make the part that makes the usb vXXXXpYYYY
part visually separated. It would only make a difference if we added further
keys with a different number of digits, which is unlikely.
-usb:v0627p0001:*QEMU USB Keyboard*
-usb:v0627p0001:*QEMU USB Mouse*
-usb:v0627p0001:*QEMU USB Tablet*
+usb:v0627p0001:*QEMU USB Keyboard*:*
+usb:v0627p0001:*QEMU USB Mouse*:*
+usb:v0627p0001:*QEMU USB Tablet*:*
Again, only a clarification. We know that ":" will appear somewhere later in
the match key, so anything that matches "…Keyboard*" will also match "…Keyboard*:*".
-evdev:name:ETPS/2 Elantech Touchpad:dmi:*svnASUSTeKComputerInc.:pnN53SV*
+evdev:name:ETPS/2 Elantech Touchpad:dmi:*svnASUSTeKComputerInc.:pnN53SV:*
This makes the match narrower. Previously we would match product "N53SV"
and "N53SV2", "N53SV3", and others. Here we are saying that the ':pn' part must
match exactly. Most of the changes in this patch match this pattern. I made a few
judgement calls and used "pn…*:*" when I wasn't sure if the full pn is included:
-evdev:name:Dell WMI hotkeys:dmi:bvn*:bvr*:bd*:svnDell*:pnPrecision*
+evdev:name:Dell WMI hotkeys:dmi:bvn*:bvr*:bd*:svnDell*:pnPrecision*:*
-evdev:name:Cypress APA Trackpad ?cyapa?:dmi:*:svnHewlett-Packard*:pnFalco*:
+evdev:name:Cypress APA Trackpad ?cyapa?:dmi:*:svnHewlett-Packard*:pnFalco*:*
This more like the "QEMU" example above, since all dmi strings end in ":", so
anything which matches the old version will also match the new version.
-evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
+evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:*
I replaced trailing ":pvr*" by ":*". This makes no functional difference because
we expect "pvr" to always appear in the dmi string. This makes patterns shorter.
-evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
+evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*:*
OTOH, ":pn*" is kept. This is because almost patterns include ":pn*", and if we
skip it, we should make it clear that this is on purpose, that we really want to
match any product name.
The python script to generate autosuspend rules is updated to use ":*" too.
Inspired by https://github.com/systemd/systemd/pull/17281#discussion_r501489750.
Different bios version includes different pn. Submitted change fixed my inverted screen after reboot.
I've stepped back to the bios version 5.11 28.04.2016 in an attempt to troubleshoot Windows Hello locking the sign
in on reboot. The screen again rotated, but 90 degrees to the right. I created a new hwdb line to resolve that issue. The bios version changes the dmi string including the svn and pn.
This fixes the broken rotation on the Acer Spin 1 I recently bought (exact model is SP111-34N-P4BZ).
It is possible that all of the SP111 models would use the same matrix, but to be on the safe side, I added a new entry.
Commit 3d864658ea ("hwdb: assume all Medion Akoya E-models have the
same matrix"), unified the entries for most Medion Akoya E* modes,
including the entry for the Medion Akoya E2215T MD60198.
But the accelerometer on the E2215T has an ACPI-id of KIOX000A, rather
then KIOX010A as the other models have, so that commit broke the
ACCEL_MOUNT_MATRIX for the E2215T.
Add a separate match for the E2215T so that it gets the correct
ACCEL_MOUNT_MATRIX again.
