Note, this change does not require the kernel running on the host is
equal or newer than 6.17. But systemd-udevd needs to be built with the
kernel headers with KEY_PERFORMANCE, and the relevant kernel header is
already updated by the previous commit.
By default, pressing Fn+F8 maps the scancode to KEY_BLUETOOTH (in evtest,
MSC_SCAN 7e -> KEY_BLUETOOTH). Windows/the manufacturer may intercept the
same scancode to execute "Launch Emoji keyboard."
On Linux, we get the "raw" KEY_BLUETOOTH code, which is unacceptable.
prog1 is already reserved by default for launching MyAsus (a Windows
application) with the Fn+F12 combination, so we will use prog2.
Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
This reverts commit 6428c0f480.
The rule seems to match not only keyboard itself but other devices.
Let's revert the change, and consider better way later.
Fixes#38502.
Asus ROG keyboards seems to send power off key code when keyboard wake
up. Reserve the key codes could suppress this problem.
Devices added: ROG Falchion & ROG Scope
Based on the work by Jon Nettleton:
https://gist.github.com/jnettlet/afb20a048b8720f3b4eb8506d8b05643
This fixes Acer Nitro ANV15-51 Nitro sense toggle
Event: time 1753852156.475850, -------------- SYN_REPORT ------------
Event: time 1753852156.565054, type 4 (EV_MSC), code 4 (MSC_SCAN), value f5
Event: time 1753852156.565054, type 1 (EV_KEY), code 148 (KEY_PROG1), value 0
We went back and forth between 'prog.sh', files('prog.sh'), and
find_program('prog.sh'). We want to use files() or find_program() so that we
get a good error message if the file is missing. Behaviour of meson changed
over time, and in the past not all forms could be used in all places. For
example 0f4c4f3824 added find_program() in many
places to avoid repeated messages. But it seems that all recent meson versions
work fine with files().
find_program prints silly messages:
Program tools/make-man-index.py found: YES
(/home/zbyszek/src/systemd/tools/make-man-index.py)
Program tools/meson-render-jinja2.py found: YES
(/home/zbyszek/src/systemd/tools/meson-render-jinja2.py)
...
We know that those files will be found, they are part of the git checkout.
With files() this is gone and the meson output is easier to read.
[1] says:
> Since 0.60.0 the name argument is optional and defaults to the basename of
> the first output
We specify >= 0.62 as the supported version, so drop the duplicate name in all cases
where it is the same as outputs[0], i.e. almost all cases.
[1] https://mesonbuild.com/Reference-manual_functions.html#custom_target
Razer has partnered with Loupedeck to develop some devices.
Add support for the following devices:
- Loupedeck CT
- Loupedeck Live
- Loupedeck Live S
- Razer Stream Controller
- Razer Stream Controller X
Add support for the hardware family, SKU (Stock-Keeping Unit) and
version. The values are read from the file /etc/machine-info or DMI as
fallback.
The entries are useful to provide an unified interface to collect detail
hardware information. The /etc/machine-info entries enable embedded
devices without UEFI support to provide the information via a common
interface.
Fixes: #31134
Add support for the hardware version. The version describes a distinct
version of compatibility hardware. The value is read from the file
/etc/machine-info or DMI as fallback.
The integration provides an unified interface to collect detail hardware
information. The /etc/machine-info entry enables embedded devices
without UEFI support to read the information from a custom store.
Add support for the hardware Stock-Keeping Unit (SKU). The SKU describes
a distinct type of hardware for sale, purchase or inventory management.
The value is read from the file /etc/machine-info or DMI as fallback.
The integration provides an unified interface to collect detail hardware
information. The /etc/machine-info entry enables embedded devices
without UEFI support to read the information from a custom store.
The goal of this PR is to replace the rules in
76aa80a6d8.
The original rules file have some rules for a device that is now
deprecated and so, are not part of this change. AFAIU, 'plugdev' is also
a thing of the past and we now use 'uaccess' which should be given to
all ID_SOFTWARE_RADIO devices. So yeah, hopefully what I have here is
equivalent to the orginal .rules.
The request for this was done here:
https://github.com/analogdevicesinc/plutosdr-fw/issues/101
As usual, it seems to be mostly additions and corrections.
The last update was in 0d740f4bc0, Dec 10th. I
think it's reasonable to update the hwdb more often. In particular, I want to
push an update to the stable branches, but it should be updated in 'main'
first.
Add hwdb entries for ADI PLUTO. Note that when in DFU (Device Firmware
mode) mode, the pid is different. Thus, the two entries.
We also want to make sure that no AT commands are sent to us and so we
set 'ID_MM_DEVICE_IGNORE=1'.
We recommend that users create overriddes. This creates the problem that there
is no syntax to unset a property. Thus, the user needs to just set the property
to "something else" in the override file. But then the blurb saying that
"VAR=1" (or "VAR=0" in some cases) is the only allowed value can be confusing.
Say that both 0 and 1 can be set, since this documentation is also intended
for end users.
In our files, we generally don't want the override values anywhere. But we
have a test which checks the rvalue, which should be enough.
We don't want to encourage people to copy the whole files. The
boilerplate text that recommends an override file rather than a
full copy appeared first in 0213a26f65,
but was added in other places in 57bb707d48.
Directly inspired by 951e8cb060, but
the wrong boilerplate was added in other places too.
Map the FN key of TUXEDO InfinityFlex 14 Gen1 that wrongly produces the F23
scancode by default.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Map the FN key of TUXEDO NB02 devices that produces a scancode unrecognized by
the Linux kernel.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
