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>
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
libratbag has a quite communication-intensive setup routine. This patch
uses short reports when possible. Using short reports will speed up the
setup process and have a lower power consumption, which is relevant for
wireless devices.
We now check the report descriptor for the supported report IDs and
adjust the report type used based on the device capabilities. Because of
that, this patch should work without any issues as the report type will
get overwritten if it not supported.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
New devices define a profile field in the button configuration. This
allows us to map a button to set the target profile as active. Even
though we don't support configuring this right now, some devices, such
as the G915/G815, come pre-configured with this action on th M-Keys.
This patch makes us able to read and write those settings, this way they
don't get lost when we write a profile to the device.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
gcc 10 complains about multiple definitions of these when linking.
/usr/bin/ld: libhidpp.a(src_hidpp-generic.c.o):/builddir/build/BUILD/libratbag-0.12/x86_64-redhat-linux-gnu/../src/libratbag-private.h:588:
multiple definition of `etekcity_driver';
libutil.a(src_libratbag-util.c.o):/builddir/build/BUILD/libratbag-0.12/x86_64-redhat-linux-gnu/../src/libratbag-private.h:588:
first defined here
Special case here is the test_driver struct, without the extern gcc seems to
think it's a new struct with all zeros, causing a segfault when we then try to
strcmp the test driver name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
