Support for this receiver, and for the device using the powerplay
receiver, still needs to be added to the kernel driver. For now, you can
used the wired connection to configure the device.
You should also not try to use with the powerplay receiver as the kernel
driver does not support the connection and won't forward any input
events to userspace.
Signed-off-by: Filipe Laíns <lains@riseup.net>
Appears to be basically the same as the V2 - the differences were
mostly in hardware (upgraded switches & image sensor). I've verified
that the list of DPI settings is correct and matches the Windows
software. Adjusting DPI config in both profiles works correctly.
We have been receiving countless issues and PRs reporting or "fixing"
the device IDs because they think it's wrong. Hopefully this will give
them an hint that is intended behavior. If they look closely at the log,
on a recent enough kernel, they should see their device show up with the
internal ID.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Bump the required meson version to match the features that we make
use of.
We now also make use of the 'copy:' keyword in configure_file that
is available in version 0.47.
Compilation on clang failed as we would try to jump to
the 'out' label and then jump over the initialization
of a variable with __attribute__((cleanup)).
We move the initaliztion up to make sure it happens before
the goto.
The glorious mice uses a single profile. To differentiate between
resolutions each one has customizable color. A led on the bottom
of the mouse shows the active resolution color.
Libratbag does not support a per-resolution color.
To allow adjusting these colors the sinowealth driver defines a led
for each resolution. This is a misuse of the model and will cause
problems when the mouse is added to Piper.
This patch removes the per-resolution leds and hardcodes the led
count to one.
Nubwo X7 Spectrum is a sinowealth-based gaming mouse.
The sinowealth-nubwo driver included in this commit provides
- LED support (except color mode that are not available in libratbag)
- DPI and reporting support
- NO button mapping/macros support
When compiling on Ubuntu 20.04 with GCC 9.3.0 and glibc 2.31, I get:
In file included from ../src/libratbag-private.h:32,
from ../src/driver-sinowealth.c:24:
../src/libratbag-util.h: In function ‘asprintf_safe’:
../src/libratbag-util.h:154:7: warning: implicit declaration of function ‘vasprintf’; did you mean ‘vsprintf’? [-Wimplicit-function-declaration]
154 | rc = vasprintf(&result, fmt, args);
| ^~~~~~~~~
| vsprintf
This appears to be because <features.h> is being included by another
header before config.h has been included. If _GNU_SOURCE has not been
defined at that point, then the other macros that control whether
vasprintf is declared are not set correctly.
Include config.h right at the top of libratbag-private.h to ensure
that _GNU_SOURCE is defined before any system headers are included to
avoid this problem.
Before this patch, ratbagd would abort initialization of the device because
no profiles are returned.
Once that was handled more gracefully, ratbagd would fail because it doesn't
read the DpiList from its own config file, as no ProfileType is specified.
Specifying G500 as the closest match.
Turns out it was caused by two mistakes:
1.) While writing the struct I overlooked a changed offset in my notes,
so a bunch of padding was missing in the middle of the struct (unk4[33]);
that padding is probably the set of colors (11) used by tail mode
2.) The LED bodies actually use RBG ordering instead of RGB
This also removes the manual addition of the universe repository, since it's already enabled in the circleci image.
Because of this, software-properties-common doesn't need to be installed anymore, and libnss-systemd isn't going to be installed (see c425780220).
However, DEBIAN_FRONTEND=noninteractive needs to be set, else the image will loop while trying to configure tzdata (aka the timezome).
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
I misread the documentation about the python3 module. The newer python
module puts the language_version in the object returned by
`pymod.find_installation()`, while the python3 module has the same
method in the *module*.
Fixes#985
This code assumes that there is a python3 or python3-embed pkg-config
file on the system, which may or may not be true. On Gentoo for example,
only python-X.Y pkg-config files are available and this will fail to
build.
This makes use of the new py_installation.dependency(embed : true) if
possible, and falls back to trying to find a python that matches the
version of python found by the python3 or python module.
