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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
(cherry picked from commit 2cf425ec573b8f67025c5e74cd267015129e7349)
(cherry picked from commit a78a52465298e8f5a927da9c9fc56c41837018aa)
(cherry picked from commit e8fe599736d70fbaf553940ea99360575637408b)
(cherry picked from commit f3eff7a838128dc690683aa94b9e1fbea3924bae)
Kernel patch [1] fixed bugs in rfkill handling on MSI Wind U100. Now
that the HW rfkill reports the correct state, and the SW rfkill is
controllable from userspace, it's necessary to mute KEY_WLAN and
KEY_BLUETOOTH generated on HW rfkill state changes. Otherwise, the
userspace will react to these keys and toggle the SW rfkill as well,
which is not desired, because the user may end up with non-functional
radios if HW and SW rfkills are out of sync.
Blocking these keycodes doesn't impair user experience, because the
desktop environment can still react to HW rfkill events and act
accordingly (for example, show notifications).
While at it, use "unknown" instead of "reserved" to mute keys, to avoid
the "atkbd serio0: Unknown key pressed" flood in dmesg.
[1]: https://lore.kernel.org/all/20230721145423.161057-1-maxtram95@gmail.com/
(cherry picked from commit fa8216e20605ff42054ee316201a13ac6cdd4cd1)
(cherry picked from commit 208a21833b6953a2517a6c3f8f4849c6664b01be)
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 MSI Summit E16 Flip A12UCT laptop sends the following unmapped
atkbd scancodes:
0x91: Launch MSI Control Center
0xf1: Toggle mic mute
0xf2: Rotate screen
The 0x91, 0xf1 and 0xf2 codes are already present in the MSI Prestige/Modern
series specific keymappings and the 0xf1 mapping is also already present in
the MSI Bravo 15-B5DX FnKeys entry.
This shows that these are generic to many MSI models, so add mappings for
these to the generic MSI mappings.
Since the MSI Bravo 15-B5DX FnKeys entry only contains the 0xf1 mapping and
that is covered by the generic MSI mappings now, that entry is removed.
Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/822
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216824
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
Follow-up for 57bb707d48131f4daad2b1b746eab586eb66b4f3.
This makes the comments in 60-evdev.hwdb, 60-keyboard.hwdb, and
70-pointingstick.hwdb consistent.
