All mice were measured using mouse-dpi-tool, and the measurements match vendors
specs, with the exception of Asus Cerberus (it officially has
500/*1000/1500/2500 DPI, but my measurements were quite different, so I opted
to include the real values).
The DPI values are based on the product’s printed documentation. The
frequency values are based on the endpoint descriptor reported by lsusb
(the mouse is a full-speed USB device and bInterval is 1 at all DPI
settings). Both sets of values are for a mouse that has *not* been
touched by the vendor’s configuration tool.
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.
