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 [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
This solves Debian Bug report 1008760:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008760.
Solution was inspired by this kernel bug report message:
https://bugzilla.kernel.org/show_bug.cgi?id=204967#c15.
My measured pad dimensions with a ruler were 85x44mm.
But I decided to take the 2x size reported by the current kernel
when invoking the touchpad-edge-detector command from the
libdev-tools package. Because this comment claims that the old
vs new kernel reportings differ by factor 2:
https://bugzilla.kernel.org/show_bug.cgi?id=204967#c3 .
Therefore I have used this command to get the new entry to 60-evdev.hwdb:
"root@pb:~# touchpad-edge-detector 80x34 /dev/input/event2
Touchpad ETPS/2 Elantech Touchpad on /dev/input/event2
Move one finger around the touchpad to detect the actual edges
Kernel says: x [0..1254], y [0..528]
Touchpad sends: x [0..2472], y [-524..528] -^C
Touchpad size as listed by the kernel: 40x17mm
User-specified touchpad size: 80x34mm
Calculated ranges: 2472/1052
Suggested udev rule:
# <Laptop model description goes here>
evdev:name:ETPS/2 Elantech Touchpad:dmi:bvnPackardBell:bvrV1.21:bd08/09/2012:br21.240:svnPackardBell:pnEasyNoteTS11HR:pvrV1.21:rvnPackardBell:rnSJV50_HR:rvrBaseBoardVersion:cvnPackardBell:ct10:cvrV1.21:*
EVDEV_ABS_00=0:2472:31
EVDEV_ABS_01=-524:528:31
EVDEV_ABS_35=0:2472:31
EVDEV_ABS_36=-524:528:31
"
It appears that exceptional layout of legacy device requires extra care of
hwdb entry for node device since Linux FireWire subsystem do not pick up
numeric model identifier in vendor directory. In detail, see:
* https://github.com/systemd/systemd/issues/25029
In the case, udev rule without model attribute is used. Thus hwdb entry
for generic AV/C device should match both cases with and without the
attribute. The wildcard added by a commit 5e577da5f8 ("hwdb: drop model
specifier from general entries") satisfies this condition,
This commit adds comment about it.
It appeared that Sony DCR-TRV310 has legacy layout of configuration ROM
against 1394 TA standard documentation.
* https://github.com/systemd/systemd/issues/25029
For the case, numeric model identifier and descriptor leaf for model name
are not picked up. This commit fulfill corresponding entry so that
applications can use model name from hardware database.
Add new key mappings for the HP Elite Dragonfly G2 laptop:
1. Map Fn+F12 (HP Programmable Key) to prog1.
2. Unmap Fn+F11 (Airplane mode) from atkbd and Intel HID events, as this
key is also reported by HP Wireless hotkeys.
* Add special keyboard combos for Thinkpad P1 Gen 3
These are based on the key codes I've found with evtest. See issue
https://github.com/systemd/systemd/issues/24814 for more details.
I'm not entirely sure what some of these keys are supposed to do,
notably Fn+RShift; this doesn't seem to do anything in Windows on
my machine. Binding them to prog# makes them available to desktop
managers' key bindings at least, in case someone wishes to make
use of this extra keybind possibility.
As usual, it seems to be mostly additions and corrections. Sadly, it seems a
bit of mojibake has crept in in various places. But it's hard to correct, in
particular because it's hard to detect all cases automatically. I think we can
ignore this for now.
When I run this a few weeks ago, ma-large.txt was gutted and 20-OUI.hwdb was
siginificantly smaller. For whatever reasons, it's back to normal now.
The Acer Aspire One AOD270 and the same hardware rebranded as
Packard Bell Dot SC need a couple of keymap fixups:
1. The switch-video-mode key does not do anything. Standard acer-wmi
maps scancode 0x61 to KEY_IGNORE since typically these events are
duplicate with the ACPI video bus. But on these models the ACPI video
bus does not send events for this key, so map it.
2. The Brightness up / down hotkeys send atkbd scancode 0xce / 0xef
which by default are mapped to KEY_KPPLUSMINUS and KEY_MACRO.
These actually are duplicate events with the ACPI video bus,
so map these to KEY_IGNORE.
The key doesn't create a release event. This is a fix to make it work properly. I made sure the product is generic to work on all Victus laptops.
This fix#23006.
This adds support for Fn+PrtSc on my Lenovo Thinkpad Extreme gen 2. Judging by the picture on the key, it should probably instead of prog2 be "selective_screenshot" (that is a possible value from judging this list e18d950ce5/keynames.txt ) but that does not register with evtest at all. With this change, evtest reports:
```
Event: time 1661081631.027773, type 1 (EV_KEY), code 149 (KEY_PROG2), value 1
Event: time 1661081631.027773, -------------- SYN_REPORT ------------
Event: time 1661081631.027886, type 1 (EV_KEY), code 149 (KEY_PROG2), value 0
Event: time 1661081631.027886, -------------- SYN_REPORT ------------
```
I am not sure if systemd is the right place to add this, if not, please refer me somewhere else.
This fixes the discrepancies in the coordinate ranges for the touchpad, touchpad in this device(NS13A2) is generic and the same one is used in most models.
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.
They're floppy disk flux readers and writers used in digital
preservation and can be broadly considered to be "analyzers" of magnetic
fluxes.
This will have the intended side-effect of giving access to the device
to users at the console, obsoleting:
https://github.com/keirf/greaseweazle/blob/master/scripts/49-greaseweazle.rules
This device implements the phone mute HID usage as a toggle switch,
where 1 indicates muted, and 0 indicates unmuted. However, for a key
event 1 indicates that the key has been pressed and 0 indicates it has
been released. This mismatch causes issues, so prevent key events from
being generated for this HID usage.
It has been shown that the autosuspend delay for this device enacted
by modem manager will race with suspend and cause system suspend
failures.
This occurred in ChromiumOS on a chromebook, but there is no reason
it won't happen in regular notebooks with the same WWAN. To avoid
the failure delay autosuspend to a frequency longer than the polling
rate used by modem manager.
Link: https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/3635003
Link: 43e76bf1bb/src/mm-iface-modem.c (L1633)
For micmute userspace handles both micmute and f20, as Xorg cannot
handle the high keycode that the micmute key has. As such, adding the
remapping means that the key will work on Xorg clients and not just when
using wayland.
Add keymappings for the Acer Aspire One AO532h netbook.
Unmap the brightnesskeys because they send duplicate key events with
the ACPI video bus key events and add a mapping for the bluetooth
on/off hotkey.
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.
