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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
