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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
Michele Perrone and Ralf Anderegg contribute to ALSA dice driver to support
products of Weiss Engineering. Their patch includes support for DAC202 Maya
edition.
* https://lore.kernel.org/alsa-devel/24703333-9250-40bf-e736-a5f3c4862034@weiss.ch/
This commit fulfulls an entry for the model as well as supplemental comment
to DAC2/Minerva.
Map Fn+Tab to fn_esc as is FnLock toggle in this keyboard. Still doesn't behave as expected because work in ideapad_laptop kernel module could be required but now at least we report the same mapping in others keyboards with Fn+ESC for FnLock and not unknown.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
* Update 60-input-id.hwdb: add TEX Shinobi
The TEX Shinobi keyboard with trackpoint incorrectly identifies as a mouse instead of a pointing stick. This corrects it as suggested at https://gitlab.freedesktop.org/libinput/libinput/-/issues/932#note_2069967
Following the example of the Lite-On keyboard entry, this modalias specifies the mouse unit without tagging the device's other entries.
We went back-and-forth a bit on this. Very old meson would print a message
about detecting the program if a quoted argument was used, leading to a lot of
noise. So we started to convert various places to use the variable, but then it
turned out that meson < 0.56.2 doesn't handle this correctly and we reverted to
using strings everywhere in 7c22f07cbd. Then at
some point we stopped supporting old meson and over time we started using the
variable in various places again, somewhat inconsistently. Then most calls to
'sh' were removed in 9289e093ae when
install_emptydir() builtin started being used.
Now meson allows either the string or variable to be used, and doesn't print a
message if the string is used. Let's use the variable everywhere. For 'sh', we
could do either, but for other variables, we _do_ want the detection to happen,
for example for git, find, awk, which might not be installed and we want to
detect that early, before we start the build. It would be ugly to use quotes
for some programs, but not for others. Also, a string is still refused for
test(), so we couldn't use the string version even if we didn't care about
detection.
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/
The TODO says we were supposed to do that in 2019–2020 (if I interpreted the
enigmatic notation correctly). The comment in hwdb said:
> DO NOT USE THIS PROPERTY. This property is kept for backwards
> compatibility. The only known consumer, libinput, stopped reading this
> property in version 1.9.0. No new entries for this property should be
> added.
… and we're currently on libinput-1.23.0.
Most likely there are no users, and even if they are, they'll just get a
slightly misbehaving pointingstick, which shouldn't be too bad.
Follow-up for 123c0e24dd.
Note, the entry was originally added for IdeaPad Flex 5 in
21b589a155.
Then, a bug introduced by 19db450f3a.
But, when it was fixed by 738a195bd5,
the glob becomes too stricter, and another variant was added by
123c0e24dd.
Correct the SOUND_FORM_FACTOR property for Steelseries Arctis headsets.
The USB IDs were all gathered from HeadsetControl[1].
[1]: https://github.com/Sapd/HeadsetControl
Hello
This pull req is adapting pull req #5772 (which fixed issue #5047), for the very similar computer Dell Latitude E6420 which has the same problem with the hardware switch to toggle wifi (aka rfkill). The symptom is the following repeated msgs in dmesg
[ 309.010284] atkbd serio0: Use 'setkeycodes e008 <keycode>' to make it known.
[ 309.016020] atkbd serio0: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0).
Adding this line to include E6 models causes these messages to stop showing in dmesg
Thank you
Like other MSI laptops the MSI Summit E16 Flip A12UCT laptop also send
atkbd scancode 0x76 for the Fn + F4 touchpad-toggle hotkey combo.
Move the existing mapping for this from the MSI Prestige And MSI Modern
section to the generic MSI laptop section.
While at it also drop the KEYBOARD_KEY_f1=f20 mapping from
the MSI Prestige And MSI Modern section, as that is already listed
in the generic MSI laptop section.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216824
This fixes the tablet buttons on the Thinkpad X200 Tablet.
My Lenovo ThinkPad X200 Tablet is called "ThinkPadX200T" instead of "ThinkPadX200Tablet":
```
$ cat /sys/devices/virtual/dmi/id/modalias
dmi:bvnLENOVO:bvr7WET71WW(3.21):bd11/29/2012:br3.33:efr1.6:svnLENOVO:pn7453WVK:pvrThinkPadX200T:rvnLENOVO:rn7453WVK:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:sku:
```
This patch makes both strings work correctly to support the extra tablet keys.
This reverts commit 81cfea95e5.
The modalias seems to match a generic Logitech USB receiver even the
connected mouce is not for left hand.
Fixes#26671 and #26676.
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
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
