Broke with Ruff v0.2.
- SIM401 Use `self._devices.get(id, None)` instead of an `if` block
- SIM113 Use `enumerate()` for index variable `i` in `for` loop
- Add type hint for Ratbagd._devices
Macros can be used for that instead, drivers can adapt them as needed.
Simple key actions will stay here for now, but I plan to completely
replace them with macros eventually.
I think we're better off ignoring the warning here (instead of repeating
the same argument like 10 times).
Fixes tests failing because UP032 was extended in Ruff (and this has
happened before). Pinning Ruff is probably a good idea. (Fixes #1515.)
Although it does work for some mice and fixes there being several
configurable devices for a single mouse in libratbag, for some mice it
does *not* apply, making them unusable with libratbag.
This erroneously declared it with name `__packed__` instead of using it
as an attribute.
It doesn't seem like it changes struct's size, but it has no
static_assert on it so we can't be 100% sure.
If by any chance returned `size` was `0`, it would erroneously return 0,
which would do an uninitialized pointer dereference in
sinowealthnubwo_probe().
This fixes a convoluted warning by clang-analyze.
Initially I made them so that you can run them separately to see their
output, however, this can be done with meson out of the box. E.g.,
replace:
`ninja -C builddir python-black-check`
with
`meson test -v -C builddir python-black-check`.
As the fields are not always keys, also don't strip the first four
symbols of the string.
(as it's not always obvious what the stripped string can be, for example
BTN_0 and KEY_0).
sd-bus requires an int variable to be passed to SD_BUS_TYPE_BOOLEAN
calls, see man sd_bus_message_read (3).
We have had an issue of the same sort recently in
77fcaf6d28 which was in some freshly new
code, but this time it's something we have been shipping for a while.
This should be unreachable because we `Driver` field must be set in
device files, otherwise they are ignored. Our tests also catch this.
Anyway, it's always better to be explicit about this.
Fixes drivers calling public API functions which should only be called
by the consumers of the library. The real problem here is that we don't
have a clear separation between driver API and public API.
This is just a simple search and replace, so there be more such things.
Not tested if it needs off-by-one adjustment like some other sensors do.
Although it could've been an ideal opportunity to add support for all of
the possible sensors, I didn't do it for the same reason.
These one-letter variable names really are bad.
A good illustration of this is resolutions being assigned to the
variable where Ratbagd was, both of such variables were always names
just "r".
NOTE: this will fail tests as of this commit, as the code is not
formatted yet.
We didn't explicitly specify a minimum Python version before that, so I
used v3.7 here, because it's the minimal version Ruff - a Python linter
I will add in the next commit - supports.
It seems like some devices now do have several profiles support enabled
officially. We failed to probe such mice if they have had non-first
profile as active. This fixes it.
A regression I introduced while modifying the disableable resolutions
patch.
It went unnoticed, because it only crashes with optimizations enabled.
In my defense, this exception in D-Bus API that boolean messages must
give address of an int and not a bool is a weird peculiarity...
Implements feature to disable resolutions from a static resolution list.
Updates DBus API and tests accordingly.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
When a boolean property is optional, the default None value and the False
value both represent a boolean false. So let's rename the property so that the
boolean values cannot be confused, because None and (Disabled == false) have
the same meaning (profile is enabled).
This is an API break.
Fixes#756
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This reverts commit 95243307ce.
I don't see any reason it has been there at all, and it also breaks
ratbag-command because of probably mistakenly removed Macro.NONE.
Add the required hooks which were largely missing, remove a check that was a
copy/paste error and add a test button.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For what it's worth, all of this may not even belong in libratbag - this
is never going to be shipped to end users, only if someone modifies the
source code. In other words all of this is basically dead code, it's
just me trying to figure out the internal of SinoWealth devices.
I first thought that we could use try to use this instead of
full-fledged macros when possible, but the implementation then is going
to look quite messy, so let's just delete this.
This moves device data out of the driver into device files. However, a
_single_ device file contains data for _several mice_ at the same time.
The reason for this is that different mice by SinoWealth may use the
same VID:PID pair. This is unfortunate, as we only allow a single
device file a given VID:PID pair.
Also move `sinowealth_led_format` enum into a header file and rename
its constants to fit in outside of the driver.
hidpp files were using the error function from error.h header file.
Unfortunately not every libc comes with this particular header file, so
with this patch we won't be requiring to be rely on error function and
use fprintf function.
Thanks to developer Yaroslav Chvanov <staticssleever668> for the
original suggestion
Closes: https://github.com/libratbag/libratbag/issues/1253
Signed-off-by: listout <listout@protonmail.com>
This variant stands for Logitech MX Anywhere 3 for Business.
Bluetooth match only, the receiver is not yet supported by the
kernel and the device thus has the receiver's USB id
Signed-off-by: Sami Olmari <sami@olmari.fi>
currently the active profile index is fetched for each profile,
this adds unnecessary overhead.
change the behavior to fetch the active profile only once during the driver data initialization.
This makes the code a bit more self-explaining and less error-prone as
we don't have to think about memory addresses when modifying DPI.
Also fixes several `bugprone-implicit-widening-of-multiplication-result`
clang-tidy warnings.
It turns out the field with active resolution only counts active
resolution slots. This was probably missed before because probably no
one sets for instance slots 1 and 3 but disables slot 2. I already added
a comment explaining this behavior before because I noticed this while
trying to implement this in ratbag-python and be surprised it didn't
work, but I didn't notice that the implementation here was lacking.
No obvious reason why we need to include that header and it appears to
be glibc-specific. Let's use stdint.h instead (which is already
included).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently, these functions will read and timeout after 1s if
no packets were received. The issue with this is that a lot of times we
may catch unrelated packets, such as mouse or keyboard changes.
To solve this, this patch adds a new optional filter argument, when a filter
is passed the functions now will keep reading packets until a valid packet is found.
The filter argument is user written function that returns true or false.
Co-authored-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Rafael Silva <perigoso@riseup.net>
Removes a lot of duplicated code.
There is one place, however, where these helpers were not used -
`sinowealth_read_raw_config`. It has some custom handling of data
because of unexpected behavior from mice.
Well, of almost all, config getter's output is not checked as it may
have seemingly incorrect data in some cases.
Potentially some mice may not support some commands but look like they
do. You can see this guard in action if you run
`sinowealth_print_long_lod_and_anglesnapping` after any other command
that sets 6 byte long buffer on non-long mice.
Also move one of them up, this may make the function a bit more readable
if we ever decide to support the second mouse profile.
Fixes a clang-tidy warning.
Although I'm not sure this if this would work on every compiler, having
a bit of extra type safety is always nice.
It does work with GCC and Clang at the very least.
Different variable names and no-one noticed.
This means we need to add a few dependencies that weren't needed before.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Right now, CircleCI fails with ssh errors because for some reason it
wants to clone the repo over ssh, not https. This is probably fixable
but CircleCI now limits how many runs we can do per month anyway so it's
borderline useless if we do actual developement.
Having to re-learn the Circle CI syntax to fix the current issue is not
an efficient use of our time, so let's just drop this completely, git
will keep the history of what we used to do in the CI for us.
02f3487f52 added a github workflow which
is comparatively incomplete but could be extended to do the previous
test runs. That's a more future-proof path anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes the need of listing every device in meson.build which is a
common enough mistake for new contributors.
And move the validation tests over to test/ so we don't have to list
them in the exclude_files of the install_subdir() command.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Released March 2019 we've already relied on some of its features anyway,
let's get rid of the warnings.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
CircleCI is limiting how many runs we can do, which results in pipelines
randomly failing when we've used up the credits for this month.
Let's add a github workflow instead. Unfortunately github workflows are
a bit of a toy api, no support for YAML anchors or extending other jobs,
so there's a lot of duplication needed to get a job to do something.
The actions added in this patch help a bit to make the jobs easier to
understand (copied from libwacom).
This only runs on Ubuntu right now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rival mice are composite devices with multiple HID devices and only the
HID vendor device can be used to configure the device.
Tested with a SteelSeries Rival 300 (1038:1710).
Fix#888
SteelSeries mice using V1 driver don't support changing LED breathing
duration precisely, so it was always locked on 5 seconds. Now we try to
match desired duration with factory preset values: 3, 5 and 7 seconds.
Judging by rivalcfg's data for Sensei Raw, Rival 100, Rival (300) and Kinzu v2 (all are version 1 devices in our data), it should have been like that from the beginning.
Confirmed on Rival 100.
Previously the scheduled task would only have been executed after some
other event woke up the mainloop.
If no such event happens, the task will be delayed significantly.
Fixes#1121
driver-sinowealth-nubwo.c was missing to include "config.h" so
_GNU_SOURCE wasn't defined soon enough.
Co-authored-by: Elián Hanisch <elian.hanisch@ing.unlp.edu.ar>
See my description of the problem in [1].
Essentially, docker is mishandling the failuire when a syscall is not
available, returning EPERM instead of ENOSYS, and making code misbehave.
The current issue with arch is glibc, which explodes on EPERM, causing
pacman to misbehave.
Once the fix hits CircleCI, we will re-enable.
[1] https://github.com/fwupd/fwupd/issues/2894
Signed-off-by: Filipe Laíns <lains@riseup.net>
This is the minimal code required to have a working driver, now we just
need a .device file.
Note the hardcoding of `profile->is_active = true` in
openinput_read_profile, this works because we just have one profile.
Signed-off-by: Filipe Laíns <lains@riseup.net>
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.
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>
Removes useless setting of the dpi index when updating resolutions.
Removes weird empty line.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
Use separate variable lists for dependencies.
Uninstall check merged in upstream meson, so it can be simplified.
`libsolv` doesn't need to be updated any more with Fedora 31.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
When the API version mismatches we want to fail early before performing
any more complex initialisation. We do however have to check for
devices first so that we can distinguish cases where we cannot access
the daemon from those where it is too old to provide an API version.
If access failed, e.g. due to insufficient permissions, don't confuse
the user by reporting an API mismatch.
This is a minimal improvement to target issue #802. As, if access is
restricted to a group, that group is known in Meson, it would even be
possible to report that group in the error message. But, that would
require converting ratbagd.py to a template or finding some other way to
inject that information at build time.
- File "./build/ratbag-command", line 2289, in open_ratbagd
r = Ratbagd(1)
TypeError: __init__() takes 1 positional argument but 2 were given
- AttributeError: module 'libratbag' has no attribute
'ratbag_device_get_bus'
- File "./build/ratbag-command", line 267, in model
return "{}:{04x}:{04x}:{d}".format(bus, vid, pid, version)
KeyError: '04x'
- swig/python detected a memory leak of type 'uint32_t *', no destructor
found.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This patch moves the 0x8100 initialization routine out of
hidpp20drv_init_feature because it needs the capabilities to be
processed first.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Bumped copyright to 2019.
Fixed typo in profile.capabilities description.
only ratbagd.py: Removed vim helper line since the file has a proper file extension.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
These are two fields of a union and should have the same value. What the
code doing here is trying to free a pointer twice.
Signed-off-by: Qiu Wenbo <qiuwenbo@phytium.com.cn>
Rename fedora_latest to fedora_31 which is more representative.
Drop the Fedora Rawhide workflow which was always disabled anyway.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
We don't want any device files that use the receiver itself as a match so
let's test for that. In virtually all cases this means the user must update
the kernel and hope support for that receiver is already present in that
version.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was copied from libinput and made sense while libratbag was a library -
we want "unhandled" messages to end up somewhere and stderr is the most likely
candidate here.
Now that we always run within ratbagd and it's all effectively inseperable,
just log to stdout for anything below error.
The switch statement was reformatted for consistency, only the ERROR case has
changed code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When no device is present, starting ratbagd even with --verbose prints exactly
nothing. Let's be more verbose here to give the user an indication that
something's happening. The user wants everything, is probably willing to
accept anything but in the end all we can say is that we have nothing.
Related to #862
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Renamed filenames to avoid brackets, and added a check to data-parse-test.py to
check for brackets, parentheses, and braces so they aren't shipped in filenames
in the future.
When the windows driver puts a device in host mode it will mark all 8100
profiles as disabled. If no 8100 profile is enabled no libratbag profile
will get enabled. This patch prevents this by marking the first profile
as enabled if no profile is already enabled.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
TBH I don't know why I wrote the original code in the first place, it
clearly doesn't follow the spec.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
Right now we initialize any hidpp10 device with one profile and then go and
fetch the data. But we never check for return codes, so it always succeeds
even when we can't get anything out of the device at all. Eventually we fail
the sanity checks with "invalid dpi list" which is confusing at best.
Let's avoid this by requiring at least the current profile to work. This will
break devices that have a single emulated profile, i.e. those that don't have
profiles but rely on libratbag to emulate one based on the
current-resolution/current-... calls. Not sure we actually support any of
those, so let's see.
Closes#738 though it doesn't fix it, it just bails out better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is confusing because we do have a test driver and we have an optional
test_device argument here too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than bail out completely, let's pretend the factory profile is profile
0 and keep going. This gives us a pretend-function mouse, though whether this
actually works is questionable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
CircleCI 2.0 requires a new config file location, otherwise it won't run. And
since 1.0 is sunset now, this means our CI wasn't getting executed.
The actual format of the config is the same, we were already using 2.0
features.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The G700 and G700s both use the receiver's product id, so they both end up
having the same DeviceMatch. One of those two never gets loaded but which one
is implementation-defined and may change accidentally.
Let's drop the G700s entry because the G700 is closer to a lowest comon
denominator. Once we have kernel support for the actual product id, we can
re-instante them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While the DBus API is still in flux, things can break at any time.
Keeping piper and libratbag in version-step works terribly, doubly so where
piper is flatpaked but ratbagd comes from some repo somewhere. We can't check
at build-time, we can't run ratbagd --version at runtime.
so let's add a version field for now and drop it if we ever get to stable.
Meanwhile, ratbagd.py will throw an exception if the expected version doesn't
match exactly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Force the tests to load a test device with JSON that matches their
expectations instead of having a magic device pre-setup where the tests have
to know what the values are.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
sd-bus encodes underscores as _5f which looks like memory corruption. Let's
skip them, they don't add value anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When building with --buildtype=plain, the build fails with the following
error:
cc1: error: ‘-Wformat-security’ ignored without ‘-Wformat’ [-Werror=format-security]
-Werror=format-security was recently added in 43def1b3a5 by #745
The sequence triggered by the ratbagctl.test suite is:
- DBus call Commit()
- ratbagd schedules the callback as idle func
- DBus call ResetTestDevice()
- ratbagd cleans up the test device
- callback is called on next idle
- boom! the device is already freed
To avoid this, we need to take a ref of the device while it's being scheduled
for the commit handling. But that blocks the object paths for new test devices
because the test device name is encoded in those paths (like "hidraw" for real
devices) and it doesn't change. So let's add a count to the test device name
to make sure the new device doesn't re-use the old device's paths.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Otherwise where the directory is used within meson.build, the prefix would be
missing. No real effect since we don't use it anywhere but let's be safe.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't rely on some other tool to install the policy file, let's just do this
in ratbagd.devel directly so it's immediately executable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Which is the same env that ratbagd uses as well. And we don't have variable
values in RATBAGCTL_DEVEL anymore, so no point in having two different
variables here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it possible to run the script against a manually started
ratbagd.devel - with a lot less effort.
And since we're don't need to be root to do this, let's move that check too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it a lot easier to start ratbagd.devel in gdb, then run
ratbagctl.devel against it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have a separate name for the devel bus anyway, the git sha doesn't
give us a huge amount of benefits but makes manual debugging a major PITA.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When there's a bug that's triggered by the test suite it's hard to figure out
what exactly crashes. So allow starting ratbagd.devel manually and run the
test suite against that process so we can gdb it.
The steps required for this are a bit insane, so the instructions are listed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because our profile struct can never have an NULL name, let's assume the
empty string equals NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're initializing them with incrementing indices, let's make sure the list is
initialized that way too. Makes things more obvious in the log when the first
profile to be queried from the device isn't profile 4.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No real functional changes since they just forward to the existing function.
But it reduces the cognitive load a bit when reading the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a leftover from libratbag-as-a-library and obsolete now that ratbagd
is our only product. Our buildtest now is simply: "does ratbagd build?" and we
certainly shouldn't require a C++ compiler.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Python 3.8 no longer links to libpython, resulting in undefined references to
Python API.
But it provides a python3-embed.pc now, so let's try using that first and only
fall back on the normal case if that fails.
See https://github.com/mesonbuild/meson/issues/5629
currently if any use profile is not valid we fallback to the firmware
profiles. this is quite annoying because the user might have only one
valid profile. this patch will keep valid profiles and only fallback to
firmware profiles on a profile by profile basis.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
when we read the memory from the device we already align the offset so
that it matches the end of the sector. for ex, for a 255 sector size the
offset will be set to 255-16.
when we copy the memory (using memcpy) we just copy the bytes that will
finish filling the buffer, ignoring that the offset was aligned. we need
to copy the full 16 bytes, otherwise it will fail when sector_size does
not align with 16.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
hidpp10_read_memory will return the HID++ error if the request fails.
right now, the error code from hidpp10_read_memory is transparently
passed through hidpp10_onboard_profiles_read_macro. This is problematic
because hidpp10_onboard_profiles_parse_macro only aborts on rc < 0 and
HID++ error are > 0.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
My MX Anywhere 2 has a different PID from the one supplied in the default .device file. This adds the PID to the device file to ensure mice with this PID get detected too.
We don't ship SVGs here anymore, so let's remove that README. And instead add
one to the devices directory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
_cleanup_ is deallocating the pointer returned by
ratbag_device_data_steelseries_get_dpi_{range,list}(). Deallocating
dpi_list results in a wrong step value, and a wrong step value then
results in a wrong step count when we try to set the dpi.
Fixes#436 and #702
And install dbus-daemon manually, until we figure out how to correctly start
the new dbus-broker this will at least help us pass the tests.
And disable nss-systemd so we don't suffer from timeouts as dbus-daemon waits
for that to time out, see c425780220 for details.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is installed by software-properties-common, but since we don't
start our container with systemd, it effectively points to nowhere, adding
nothing but a delay of several minutes.
That delay affects dbus-daemon on startup and on configuration reload, it
takes several minutes to do either. ratbagctl.test installs a custom dbus
config file to be able to connect to ratbagd.devel, that config file triggers
a reload in the dbus-daemon. Since that reload takes longer than any of our
timeouts, the tests eventually fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At some point meson #defined NDEBUG depending on the build type, thus
disabling asserts. libratbag relies on those, so let's error out if NDEBUG is
defined.
Related #685
There is no guarantees the current value of dpi_index will be correct.
On my G502 the profiles are read in reverse order meaning that setting the
dpi_index can be applied to a wrong value.
Look for the correct libratbag dpi index before setting it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Where a profile name is not UTF8 compatible, let's try to convert it from
latin-1. If that fails, we just escape anything that's not ascii and move on.
Fixes#617
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For two dicts x and y the merged dict can be created as {**x, **y}. We use
that to take the enum names and covert them to lowercase with hyphens instead
of underscores.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rough update but headed in the right direction
* Simplified silhouette of bag
* Reduced number of rats inside the Rat Bag to two
* Eyes are still small and potentially still not printable at small scale
* Introduced rough stylized logotype based on Google's Sedgwick Ave Display font
* Reduced total file size by a heap
Instead of multiple entry points for different values, make the button mapping
a single entry point that takes the mapping type and a variant for the value.
The ratbagd.py bindings are basically left as-is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GObject silently catches exceptions and logs it to stderr without ever passing
on the exceptions. Avoid oversight by checking stderr in the tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No longer needed now that the ReportRate is in the profile
(bf127d4c68) and the separate
x/y resolution capability is implied by the Resolution value
(8e9dd6f392)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't have mice that can do report rates per resolutions, so let's not
commit to that.
This is a DBus API break but also a break in ratbagd, piper will need to
update to fetch the rate/rates from the profile object now.
It's a ratbagctl break as well, ratbagctl info changes slightly and the
resolution is not argument anymore for the rate.
Fixes#645
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since 2607114709 we returned the second parser
to handle everything after the device argument. That parser didn't have the
various options we handled in the original one, causing --keepalive to stop
working. Restore this by passing the existing namespace down to the parser.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a fixed (uu) with an extra capability flag, let's just make this a
variant defined to be a u or a (uu), depending on whether we have a single or
a separate resolution.
In the ratbagd.py bindings we return a tuple for both, but a simple len()
check will tell us which one it is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the specific name isn't the list (e.g. howling-woodrat) do a basic string
search on all the device names. For the normal case where users have only one
or maybe two devices and they have unique model names, they can do
ratbagctl "Logitech G303" info
Which is something we can easily support forever as sensible API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This seems like a convenience thing, possibly dating back to when we thought
ratbagctl will be the primary libratbag interaction. Either way, for the
limited number of commands we have here it's better to be very strict in what
we accept to avoid accidental typos making it into the API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ratbagd uses GObjects and properties so we also make use of notify() a
fair bit. Make sure we don't crash out in ratbagc for that, just add an empty
noop function named notify()
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Take the first 4 bytes of the device id (a sha), parse them as two 2-byte hex
values and mod them by the length of a pre-determined array of rodents and
their vocalisation methods. This gives us an index and a device name
assignement like this:
wailing-squirrel: Logitech G500s Laser Gaming Mouse
warbling-groundhog: Logitech MX Anywhere 2S
humming-hutia: Logitech Gaming Mouse G303
This relies on the sha's first 4 bytes to be unique enough that they don't add
up to the same 2 values. Which is probably safe enough.
This does not affect ratbag-command which still uses the hidraw nodes
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Device is an object on DBus, there is no need for another opaque ID, we
can just emulate this in the client. In our case by using the object
path and generating a sha1 from it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having the device node last makes it easy for us to test the same line
on various devices. That is not the most common use-case - normally we'd
expect our users to have one mouse and run several commands on it
(that's the case during debugging as well).
So let's change the device node to be the first argument, it makes for
easier typing/copy-paste, etc.
Plus it makes it a lot more obvious which one the full command is
(`dpi set 800` in this example)
```
$ ratbagctl hidraw4 dpi set 800
```
Fixes: #635
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
See the earlier commit "Drop the SVG handling from libratbag" for an
explanation, this commit merely removes the actual files from git.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The SVGs must not be part of any stable API, there is too much behavior
implied that we cannot/do not specify. So it's perfectly likely that a future
change in the SVGs or rendering libraries breaks things in some detail. But
then we cannot update the SVGs without risking breaking other clients that
rely on the current behavior.
Besides: we only have one theme, called "gnome" because a push
towards having SVGs for other themes never happened.
And that theme isn't gnome-specific, it merely looks GNOMEy. The theme is very
much piper-specific in that it requires certain elements that piper cares
about. Currently anyway, if we make this part of our API, piper cannot change
that behavior ever without breaking others.
So let's drop SVG handling completely and rely on the clients to sort it out
for themselves.
For now the SVGs are left in the tree to make it easier to copy to Piper. Once
that's done, we will remove those too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the SVGs need to be maintained elsewhere, we need something reliable to
match devices with SVGs. The easiest is to provide a unique model string,
usually composed from the usb/bluetooth information.
A string format was chosen to make it more flexible for the glorious future
where we have something other than usb or bluetooth devices. Meanwhile, the
format is the well-known "usb:1234:56ef:0" string (bus, vid, pid, version).
The version in this string is a future-proof safeguard for libratbag. It will
be used where libratbag supports two devices with the same VID/PID and where
this is not otherwise differentiable. We don't have any such devices yet, so
libratbag just returns a hardcoded 0.
The format is currently defined for usb and bluetooth, in the future we may
have other strings.
The base guarantee is that this is a reliable identifier for the model that
will never change for that model. IOW this is what piper can use to map
devices to their SVGs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The led type was the physical led type to describe where the LED sits.
This property is basically unused and of questionable use anyway. GUI
applications would need to rely on drawings of the mouse anyway. Scripts don't
really care because ratbagctl uses the led index anyway. The only time this
matters is when we're looking at (human) device discovery. But even then just
trying to set the LED is enough to figure out which one is which.
So let's drop this API on the assumption that it's not really needed and
maintaining and extending that enum forever is not necessary.
This is not a full purge, merely the DBus API that gets dropped.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The button type was the physical button type, not the logically assigned
button number.
This property is basically unused and of questionable use anyway. GUI
applications would need to rely on drawings of the mouse anyway. Scripts don't
really care because ratbagctl uses the button index anyway. The only time this
matters is when we're looking at (human) device discovery. But often clicking
around is enough to figure out the index.
So let's drop this API on the assumption that it's not really needed and
maintaining and extending that enum forever is not necessary.
This is not a full purge, merely the DBus API that gets dropped.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make this implict - if the profile has a name, it's writable. Otherwise it's
not and you'll have to rely on the index or make up your own naming.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the have all moved or been removed, there is no need to keep this
API.
This is a DBus API break, the Capabilities property disappears.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is arguably a profile-specific thing since the device itself is static
(we still know button numbers, etc.), we just don't know the content of each
profile.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have a profiles/resolution/button/led, we can write to it. That is the
default assumption and where we don't have write-access to those, we should
simply not expose them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have more than one profile, we can switch between them. Because
otherwise having more than one profile is just showing off and we don't like
that type of behaviour, no no.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This capability is superfluous. If we have more than one resolution, we can
switch between them because ... well, why have more than one then?
Signed-off-by:Peter Hutterer <peter.hutterer@who-t.net>
This is a profile-specific capability, not a device-specific one so let's move
it there.
Arguably, the DBus API should not expose SetEnabled() where not available, but
that's a separate issue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Theoretical case is where some profiles cannot be set to be the default, but
realistically: this is a profile-specific attribute so let's move the flag
there.
Arguably, the DBus API should not expose SetDefault() where not available, but
that's a separate issue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We still need to read the data of all other profiles. This broke in f26de4bb,
the previous loop only did the is-active modification
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't want anyone to rely on a specific content of the ID, e.g. by
hardcoding hidraw/event node numbers. So let's make this an opaque list with
no meaning other than "this is a rodent".
This is solely for the benefit of ratbagctl which uses these IDs as access
identifier.
This doesn't affect ratbag-command which still uses device paths. It also does
not affect the object path. And piper shows the device name anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Almost the same placement, but the horizontal line that github uses to render
headers doesn't get cut off anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
First time I viewed this was on mobile, and the logo left enough space for a
lonely "li" on the left, with the "bratbag" in the line below the logo. Let's
call that a design faux pas and make it small enough to scale.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We started with event nodes for some reason lost in the distant past (probably
because that's what a lot of other tools use). But since we exclusively deal
with hidraw devices here and event nodes only serve to look up the hidraw
node, let's get rid of that indirection layer and work with hidraw directly.
Note that changes how ratbagctl works, it used the event nodes before. So
anyone who hardcoded the event node in one way or another is going to see
breakage. Then again, the "eventX" string was the device ID as advertised by
ratbagd, so it's supposed to be treated as an opaque string anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Strings on DBus need to be valid UTF8, some of the default profile names on
the G700 include the degree character (" Profile n° 1"), the whole string ends
up being invalid UTF8.
This results in two issues:
- ratbagd gets quietly kicked off the bus when it sends that string
- ratbag-command throws an exception because Python is unhappy about the
non-UTF8 string:
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcb0' in position 3: surrogates not allowed
The quick workaround here is to strip anything that's not ASCII from the
profile name. The same may be necessary for some device names too, but let's
wait until we see that.
For ratbag-command we convert the string to bytes and back using the 'ignore'
argument, this way we should see the original profile string without the
printf errors.
This is an incomplete fix, we'll have the same issue if a user tries to set a
non-ASCII name. The long-term fix is to convert whatever we have (probably ISO
8859-1, but can we detect that?) into UTF8 before passing it around. That
would also mean converting it back before writing to the device.
Fixes#617
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't install the default SVGs anymore and all the effort for new mice goes
into the gnome theme.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Coverity seems to think this can use uninitialized array elements but that can
only happen when hidpp10->dpi_count is 0. In which case the callee doesn't
touch it anyway but coverity doesn't care about that bit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Noteworthy: "Description" has been renamed to "Name" ages ago in ratbagd, this
just corrects the documentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This isn't used by anything in the tree and Piper doesn't use it either.
(`ratbagctl` queries it from the sodipodi name in the SVG).
Plus, assuming we run sandboxed the filename is useless anyway, `GetSvgFd()`
takes care of this bit though.
So let's drop this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scan-build is at the point where it gives us too many false positives to be
reliable and they're not easily fixable other than sprinkling
"ignore_clang_sa_mem_leak" comments all over the source.
This caused us to drop F29 from the CI earlier, see 1225f421c0, but
really we just shouldn't use something that's so unreliable as part of our CI.
The main issue continues to be the use of __attribute__((cleanup)) but others
give us false positives too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
toolbox.py:86: DeprecationWarning: time.clock has been deprecated in Python
3.3 and will be removed from Python 3.8: use time.perf_counter or
time.process_time instead
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use the default Python class, it's not perfect but still makes more sense than
the javascript class.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The SVG guidelines specify a minimal vertical distance of 40px. There
were two lines in the G Pro SVG that had less, leading to the buttons
overlapping. This is visible in #607.
The elements that were supposed to be in the Device layer were
accidentally placed in the Buttons layer, making Piper not render them
in the button page.
Fixes#607.
* data: added Logitech G603 svg
* data: added Logitech G603 svg
* data: added Logitech G603 svg
* data: updated Logitech G603 svg
I fixed an issue with the right and left click buttons missing and the middle button being on the incorrect layer. I also removed the logo on the mouse as I was having some issues in Inkscape due to my unfamiliarity with the software. I figured properly configured buttons is good enough for the time being.
This brings initial support for the Logitech G402, as discussed in #471.
I used the G502 svg and modified it, without changing the graphics. The two mice are aesthetically similar.
* Added G402 device file
* Added G402 svg file
* Add G402 files to build
[bentiss] squashed the 3 patches as one
As mentioned in the code:
We revert to HW control of the LEDs.
This effectively disable the capability of changing the DPI/profile
LEDs, but this allows to make them work with the internal DPI/profile
switches.
The net result is:
- DPI/profiles can't be controlled (but who wants this?)
- The logo can properly controlled
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Since a0830a8aaa, we can re-add the simple
keybindings capabilities. It's time the HID++ 2.0 devices get this.
This used to be working with the KEY API, but this has been dropped in
favor of the macro one.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
* tools: canonicalize path first in udev_device_from_path
This fixes a problem in which running ratbag-command with the path to a
device node symlink (e.g. /dev/logi-g502 -> /dev/input/event4), such as
one created by a udev rule, would not work correctly, due to the code
failing to resolve the symlink prior to checking for the presence of the
"/dev/input/event" prefix.
This resulted in nonsensical error messages (shown below) and the
curious inability to run ratbag-command successfully with anything but
the actual raw path to the device node itself (e.g. /dev/input/event4
would work fine, but /dev/logi-g502 would not, despite both being valid
ways of getting to the same device node).
Error: Can't open '/dev/logi-g502': Success
Error: Device '/dev/logi-g502' is not supported
Note that this same problem also prevented the usage of autogenerated
symlinks by udev, i.e. '/dev/input/by-id/' and '/dev/input/by-path/'.
* Update tools/shared.c
Co-Authored-By: jgottula <justin@jgottula.com>
A non-zero value for the remapped field means the button is mapped to that
button.
"diverted" means to decouple it from normal HID reports and report it via
HID++ only. In our case here, we "map" it, which is different.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ratbagd now implements commit as normal always-successful call with a
potential Resync signal later if something failed on the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add HIDPP_PAGE_RESET, HIDPP_PAGE_DEVICE_NAME, and
HIDPP_PAGE_WIRELESS_DEVICE_STATUS. These feature names are found in the
"features.xml" of an LogiOptions installation. Probably not very useful
for now.
The MX Anywhere 2 mouse has a problematic special key (index=7). When
trying to get the reporting value of this key, the device returns an
"invalid argument" error. [1]
To avoid giving up all good information about other keys, ignore error
(and the cause) when enumerating special keys.
[1] https://github.com/libratbag/libratbag/issues/558#issuecomment-439732655
Schedule the actual operation as a callback to handle at the end of the event
loop and return success. The Resync signal will handle the rest.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A few of the device files didn't get installed, let's add them to the list.
This reshuffles the list a bit because the easiest way to make sure all files
are included is to run git ls-files, so let's stick to that.
Fixes#552
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This wasn't added to the meson.build file so the test didn't run on it. And
the test fails. Issues found include:
- DPIRange and DPIList must not be in the Device section
- Only one of those two, not both
- The svg file was in the 'default' theme rather than in gnome
This needs to be fixed first, not sure how this would've worked at all.
This reverts commit 2371960a1d.
ratbagd is not something that needs stay around forever just because we
configured a mouse once. We have DBus activation and we don't store anything
anyway, so we might as well exit after a period of inactivity (20 min).
There's a slight race condition where if something comes in at exactly the
20min mark, we may shut down anyway and the messages get lost. This is too
narrow to worry about.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turns out this driver never got updated for the 'new' DPI list provided by
libratbag and thus broke with bacdab2596 when we
enforced that DPI list.
Set a fixed DPI list based on the hardcoded values we use elsewhere in this
driver.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Notable: parts of the instructions have been punted to the wiki now where it's
faster to edit and be verbose about the specific instructions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This reverts commit 874d7eccb8.
Looks like 18.10 fails at every pipeline build, so better
punting this for later.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
I'm pretty sure all callers rely on this command to return either 0 or a
negative errno. There's a quirky occasion where if we get a HID error (a
positive number) during hidpp20_special_keys_buttons_get_reporting, that
number eventually ends up as the 'num_controls' value in
hidpp20_special_key_mouse_get_controls().
Since the only time we care about HID++ errors is during
hidpp20_root_get_protocol_version, let's just always return -EPROTO on HID++
errors.
Fixes#558
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
- New svg and device file. Updated meson.build.
- New device version (version 3).
- Refactored led cycle to be general for v2 and v3.
- New defines for v3.
Some change in F29 breaks the CI runs, so lets switch back to what we had
before so we can merge patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we can successfully read a profile but hidpp10_get_current_profile() fails
we end up with one profile, but not set to active. Fix this by always forcing
the single profile to be active.
Fixes#526
Taken from libinput, we need to define a few gcc7 types that coverity doesn't
know about. To submit a coverity build, run meson with -Dcoverity=true
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ratbagctl requires 'eventX' as argument, but ratbag-command requires
/dev/input/eventX. That's not smart, let's do better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ratbag-command has an 'except RatbagdDBusUnavailable' line despite that class
never being defined. That's ok because we'll never throw it in this case but
it's still confusing (to flake8). So let's change the class name to something
more generic and define it in ratbagc.py
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we're sandboxing the client we don't have access to the SVG files directly.
So pass a read-only file descriptor to the client over DBus and let them deal
with the SVG that way.
In ratbagd.py we pull the fd off but we convert the quirky dbus error into a
normal FileNotFoundError(), much easier to catch in the caller.
On the ratbagctl side we now have to search the SVG for it's name - stored in
the 'sodipodi:docname' attribute by Inkspace. This isn't guaranteed to exist
or be always correct, but meh, it's close enough. We could continue to use the
GetSvg() call here but I want to deprecate that and remove it in the near
future.
Fixes#521
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Without --verbose ratbagd just starts up with no message whatsoever. It's hard
to tell if any devices are supported or if the server just hangs. Let's log
the devices detected by default, at least that way we get some feedback.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Open an extra hidraw to read current onboard settings.
Initially DPI and static LED color can be read from the rival
310. Other data/devices can be added as the protocol is better
understood.
The protocol used to extract the data seems to be both device
and firmware version specific. To be able to switch on both
cases we now store the firmware information in the drv_data.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
For some devices we have to send reports on one endpoint
but read the reply on another. This commit allows us to
open and store multiple hidraws and adds API to specify
which hidraw to use for open, close, and read input report.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
Make sure we log an error if any of these fail, because most really never
should, they're scaffolding we rely on to send the data. Some of these calls
(the *_read() ones) could fail if a client sends wrong data, but we might as
well log that.
This patch only wraps calls that reply on the bus, normal sd_bus_* calls that
we catch the error ourselves are handled as before.
Likewise, any errors from libratbag are left as-is. We somewhat rely on
libratbag to log something and such errors are not a failure of the actual
scaffolding.
This should make errors like https://github.com/libratbag/piper/issues/237
easier to debug.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In some cases we get Piper trying to use None as a list, see
https://github.com/libratbag/piper/issues/237
This can be reproduced by returning an error (e.g. -ENOMEM) from
ratbagd_get_devices(). That error isn't handled anywhere on the client side,
the effective result is that the property is None when calling
proxy.get_cached_property().
The error is visible on the bus:
method call time=1535084121.223284 sender=:1.1311 -> destination=:1.1310
serial=7 path=/org/freedesktop/ratbag1;
interface=org.freedesktop.DBus.Properties; member=GetAll
string "org.freedesktop.ratbag1.Manager"
error time=1535084121.223433 sender=:1.1310 -> destination=:1.1311
error_name=org.freedesktop.DBus.Error.NoMemory reply_serial=7
string "Cannot allocate memory"
Make ratbagd.py more robust here and always return an empty list for those
properties where we expect an array. This papers over the real bug which is
that a) we need better logging in ratbagd on errors and b) something on the
other side needs to handle this error.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Clients e.g. ratbagctl ask for all properties, so this getter gets
called often even if the button is not a special action.
We do not want to send the value for an invalid special action as
that is negative 1. Converting to unknown is good enough here so
let's just remove the error logging and convert in silence.
Before we send something as "u" down DBus, check that it's not -1, a commonly
used error code in libratbag. If so, return a dbus error instead and log where
this occured so we can fix it.
This should at least help spot these errors quickly while at the same time
hopefully not crashing piper anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allows systems that provide libelogind (which provides a portion of
libsystemd that libratbag uses) to also compile without having to patch
out the rest of the build to remove the full systemd dependency.
This commit:
- Adds a systemd swith on meson_options.txt, a boolean set to true as
default to keep expected behaivour
- Adds a check on meson.build for the systemd switch and adds
dep_systemd
- Guards sections meant to generate systemd service units under the
systemd switch
Some devices like the logitech G9 have a button in its profile
data which is not a real physical button. This breaks the direct
mapping from button number to profile number.
This patch reduces this case from an error to a warning
After some "user testing" (having a friend try it), I've put the side
view back in. This has the benefit of keeping all buttons visible
without overlap, which would be necessary for
https://github.com/libratbag/piper/issues/71.
A driver for the logitech G600. The behavior is similar to the
G300 but with enough differences that it seemed cleaner to implement
as a separate driver.
../src/liblur.c:46:3: warning: 'd' may be used uninitialized in this function [-Wmaybe-uninitialized]
hidpp10_device_destroy(*hidpp10_device);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/liblur.c:198:59: note: 'd' was declared here
_cleanup_hidpp10_device_destroy_ struct hidpp10_device *d;
And similar messages
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was nasty. We correctly set the number of buttons but rely later
on the field set in drv_data.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Given that there is a sanity check on the available resolution, we
need to provide default values. There might be a way to fetch the
actual values from the hardware but at least provide some sort of
default that re-enables the hardwares.
Fixes bacdab2596
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
https://bugs.llvm.org/show_bug.cgi?id=3888
clang analyzer doesn't know how to handle __attribute__(cleanup()).
There are only 2 warnings raised because the analyzer only look at the
current compilation unit for checking the malloc call. So only those
2 are detected by clang and then marked as memory leak.
This also means our current continuous integration doesn't check for
memory leaks.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
value and dpi are unsigned so the delta calculations was wrong when
dpi is larger than than value. Casting to int should be fine for the
expected range of values in those variables.
Adds a setting to specify the max length of key press macros that the
device supports.
Setting MacroLength to 1 means that the device supports normal key presses,
(key + modifiers) but not multi key press macros.
0 can be used to indicate that buttons cannot be set as keys at all.
Initial support for the original Rival mouse.
Setting resolutions, report rate and LED color and
modes.
No key mappings yet, and breathing duration is fixed.
The steelseries mice have 2 resolutions. The range/interval
is different per device. We cannot query the devices, so we
have to pick some defaults. Before we took the two first in
the list to be safe. It is a pretty bad default though. Using
800 and 1600 is supported by all known devices and seem as
more reasonable defaults.
The default button mapping the sensei 310 does not match
the table for the two known steelseries mice. The 6th button
is no longer resolution cycle, so the single table no longer
fits. Let's construct the table depending on the number of
buttons on the device.
This change makes it possible to pass '-Ddbus-group=<group>' to limit
the access to the ratbagd D-Bus service. The default remains to allow
everyone access to the service.
This allows integrators to choose more conservative security settings
e.g. only allowing users in the 'games' group to talk to the ratbagd
daemon.
To specify the colors to cycle trough we write a list of
colors and their individual share of the total cycle duration.
Solid colors only have a single color in their list.
Breathing mode will cycle to and from the picked color and black.
Cycle mode will cycle through red, green, and blue.
When using ratbagctl.devel we would use the .device files
from the source dir. This patch also makes it use the .svg
files from the source dir. This makes it easier to edit the
svg and less surprising now that it follows the .devices files.
To match the source file layout the .devices files are now
installed into a 'devices' subdirectory.
The steelseries driver used some hardcoded values for as the
only supported device was the rival 310. This moves that data
to the .device file.
The default resolutions used are changed from hardcoded 1000
and 2000, to the two first entries in the dpi list. Picking
actual values from the specified dpi list or range is safer.
Add a section in the .device files for SteelSeries mice.
The mice cannot be queried and we need to store data for each
device of number of buttons, leds, and dpi list/range. Lastly
a "device version" is added. The latest models use a slightly
different protocol, so we needed something to distinguish them
with.
Set the list of DPIs directly instead of use the _from_range call.
The G300 has few and coarse resolution options. Using the
exponential'ish range is not a good fit for devices with so
few dpis.
The logitech G300 can set:
250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500
but piper would offer:
250, 300, 350, 400, 450, 500, 550, 600, 650, 700, 750,
800, 850, 900, 950, 1000, 1100, 1200, 1300, 1400, 1500,
1600, 1700, 1800, 1900, 2000, 2100, 2200, 2300, 2400, 2500
We overpromise by offering more finegrainded options than the
mouse can do and end up with three times as many options than
we should.
No-one appears to be using these and the efforts to create SVGs
go into the GNOME ones (used by piper). Leave them in the git tree in case
someone wants to pick them up but until we have a consumer it's not worth it
installing them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libratbag@sha/libratbag.c: In function ‘_wrap_error__varargs__’:
libratbag@sha/libratbag.c:6392:3: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
error((char const *)arg1,arg2);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There is no point anymore to have an extra 'action' argument, and make
both type of function look the same.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
action->macro is supposed to be allocated once and stay for the
entire life of the button. However, it was outrageously overwritten
when setting the action. Take some actions and keep the macro action
around.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The driver does not yet support button mappings or any
non-solid LED modes.
The device does not support reading out the current
configuration. On probe some default values are used
to get a usable profile.
The bitmask in the 8060 report is for ms between reports. We could do all, but
really we only care about a few resolutions, anything else is too niche to
bother with.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least in the DBus API we can't just say "doesn't exist", so let's allow for
a zero-sized list.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
$> flake8-3 tools/ratbagctl.devel.in tools/ratbagctl.in tools/ratbagctl.test.in .
tools/ratbagctl.in:166:1: E302 expected 2 blank lines, found 1
tools/ratbagctl.in:173:25: E201 whitespace after '['
tools/ratbagctl.in:173:68: E202 whitespace before ']'
tools/ratbagctl.in:314:1: E302 expected 2 blank lines, found 1
tools/ratbagctl.in:318:1: E302 expected 2 blank lines, found 1
tools/ratbagctl.test.in:281:43: E261 at least two spaces before inline comment
tools/ratbagctl.test.in:302:31: E261 at least two spaces before inline comment
tools/ratbagctl.test.in:306:43: E261 at least two spaces before inline comment
tools/ratbagctl.test.in:337:43: E261 at least two spaces before inline comment
tools/ratbagctl.test.in:576:1: E302 expected 2 blank lines, found 1
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This one gets a little bit meesy given that the libratbag expects a
C array. Provide some wrapping aound it and hope we won't have to
do it again and again.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We do not need to parse all the devices, but only the one given in the
command line. Make ratbagc.py handle this case properly.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
And use it to create ratabg-command.py
Benefits are that we bypass ratbagd, meaning we can attach gdb or run
valgrind on the tools themselves.
Problem is the python wrapper doesn't clean up after itself, and so
running valgrind is moot
Fixes#274
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
To be able to query which modes are available.
Exposed via ratbagctl as
./build/ratbagctl.devel led 0 capabilities event4
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We are reusing a lot the fedora container, but we need to always download
and install the same set of packages. Store them in the workspace to
speed up the tests.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Note that the push requires a specific private key in the libratbag
circle CI organization, meaning that only the master branch of libratbag
will be allowed to push to the doc repo.
Note also that only the master branch will trigger the request:
- any PR will not trigger the request
- any push on the master branch of a personal repo will fail while
attempting to write the docs, if the repo is setup to use circleCI too.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If our device only has a discrete number of DPIs, pass it on as-is to
libratbag rather than pretending it's a range and then failing to set the
DPIs.
For the actual ranged devices we use libratbag's now-exponential range
mapping rather than passing all possible ones on. This relies on us having the
same steps that libratbag uses, should be safe enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we could get a min/max value but there was no guarantee that it
any value in between would actually work on the device. Some devices have a
discrete number of resolutions (e.g. 500, 1000, 2000, 2500), most others have
at least a minimum step size (so 1234 isn't a valid dpi value).
Change the min/max to a discrete list of which resolutions are supported. This
allows a UI to adjust its interface dynamically - e.g. a combobox if there are
only 3 resolutions or a slider if there are a million of them.
This is a DBus API break
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Better than the markdown we were using before, even though we're currently
(ab)using the js/c++ domains for the structure. There is no DBus domain in
sphinx yet.
The main motivation was to get the enums into the documentation since they are
exported ABI.
Generating the documentation is quirky - we use doxygen to extract the
comments from the C header file and then use XSLT to convert to .rst which
sphinx can use. Still better than having to maintain even more copies of the
enums.
Since this is only of interest for maintainers that need to upload the
documentation, it is turned off by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libratbag is not a library anymore. Move all the stuff that we need for the
DBus interface (i.e. the enum values) into its own header file so they're
all in one place and we don't have to worry about it anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, probe() would call ratbag_init_profiles() which in turn would call
the various function pointers in the driver to fill in profiles, buttons and
leds (the latter while filling in profiles). This made the probe() function
harder to understand than necessary and unreliable because it wasn't always
clear which bits were already set up while some driver function was called and
which ones weren't yet.
This patch switches to a flat probe(). The driver still needs to call
ratbag_init_profiles(), libratbag sets up everything (to default values). Then
the driver can fill in the rest as it wants.
This patch still makes use of the current infrastructure, the drivers
just call the read_profile and read_button functions manually now.
Fixes#370
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Resolutions were still stored in an array over a linked list like the
buttons/leds/profiles and initializing them from a driver was different than
buttons or leds. This brings the resolutions in line with the buttons and
leds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We can't guarantee it's a sysname even though that is what we use for evdev
devices. Future devices may just be some custom-assigned name for a remote
dbus API
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least on HID++ 2.0, the LED types appear to be random and don't match the
protocol specs. Other protocols don't even have those bits, so let's make this
a generic entry.
This is pre-filled for all LEDs but drivers can override it where required.
Fixes#377
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tools/ratbagctl.in:146:92: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:147:92: E126 continuation line over-indented for hanging indent
tools/ratbagctl.in:154:91: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:155:91: E126 continuation line over-indented for hanging indent
tools/ratbagctl.in:161:118: E128 continuation line under-indented for visual indent
tools/ratbagctl.in:162:118: E126 continuation line over-indented for hanging indent
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
A driver is supposed to know what type an LED is, unknown doesn't help anyone
here. So replace this with a private #define and abort when a driver doesn't
set the type. This also adds a requirement that any driver initializing a LED
must have the read_led() function, otherwise we can't fill it in correctly.
And bump the enum up by one, the first valid value should start at 1 (or some
other non-boolean value).
Related #365Fixes#364
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If HIDPP_PAGE_COLOR_LED_EFFECTS fails but the profile returns a nonzero LED
count we crash later in hidpp20drv_read_led() because all the led info is
null.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
struct hidpp20_led_sw_ctrl_led_info holds a u8 for the .type field.
Attempting to convert a value which is already a u8 ends up setting
0 and thus discarding the type information.
Fix by removing the extra step.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
With the swtich to the commit style the function
hidpp10drv_write_resolution_dpi is doing too much work.
Before commit style the function would:
* get the profile
* get the current resolution
* write the profile (resets it to default dpi)
* set the current (updated) resolution
With the commit style we call the function for every resolution
in every dirty profile we now:
* get the current resolution
* set the current (updated) resolution
Then later:
* write the profile (resets to default dpi)
This patch changes this to only doing one set of the current resolution
when the active profile has been written. This reduces the traffic to the
device and sets the current resolution after the profile write.
It's a fixed value so it's much easier to set this in the test binaries rather
than requiring the user to set this in the env before running a test manually.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For the device I have I do not see a way to get
this information by querying the device.
If the value is set in the .device file it will
override anything that the hidpp10 driver itself
would have found.
1-bit RGB is needed for the Logitech G300, let's rename the main RGB to
indicate how many bits we actually have.
See #335
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since we unconditionally call unlink() on that path later, let's make sure
we actually copy to that file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The initial value of 400 in the enum is chosen so it looks weird when someone
tries to interpret the value as integer. Values of 1, 2, 4, etc. could be
confused with something realistic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Writing multiple changed profiles was broken as we would exit the
loop after the first profile write. We were returning the number
of bytes written and this was interpreted as an error.
Fix it my returning 0 when we have written the correct number of
bytes to the mouse.
If we could not start the process, there is a high chance we are running
the tests against a different ratbagd implementation so there is no point.
Also, an exception will get raised later during the tear down of the
module saying that "'NoneType' object has no attribute 'terminate'".
This is less than ideal to notify that the process has not been started.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If the other commands try to access a node, there will be an other error
("Unable to find device X"). So there is no points in having this as a
global check.
For the .devel and .test versions, we are guaranteed to have the
test_device at least, so no worries on this side too.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If a profile is either wrong or not there, we rely on the ROM to get
a correct profile.
Fixes#280
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The driver is supposed to prepare everything in memory and then, at the
end commit on the device.
Bug #280 is still not fixed as we should initialize empty profiles first.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Only reading/writing full sectors are allowed (because we need to set and
read the crc anyway).
Fixes#122
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
allocate was actually both initializing and allocating through initialize.
Things started to get complicated.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Starting with -vv, we print out the ratbagd log messages to stdout/stderr,
-vvv switches ratbagd to raw mode. We start at level 2 so that we can have the
single -v reserved for ratbagctl itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For the active profile we read the active resolution
from the mouse during probe.
When changing the active profile we set the default
resolution to active.
Plan is to remove the key mapping altogether and make it transparent from the
Macro mappings (in libratbag/the drivers). Meanwhile, remove the DBus API so
nothing can actually start using it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that we use the .ini style device configuration and everything has been
migrated, we don't need the hwdb/rules files anymore
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we leave ratbagctl.devel too soon, ratbagd gets killed before it even
receives the async call for commmit(), meaning everything we do on the
device is lost.
0.5 is empirical. It seems on my system 0.2 is enough (0.1 doesn't seem
to work). Hopefully this value is not device dependent.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
not sure why, but stat.S_IEXEC only sets exec permission for the user,
meaning that the installed file can't be run by anybody else than root.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It always bothered me that it was in the middle of the normal ratbagd, which
made fiding it more effort than neccessary. Split it out into a separate file
so it's easily identifiable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A quick and easy way to sync anything coming from dbus (like property updates)
without needing to be hooked into a glib mainloop directly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not sure why it thinks we're potentially dereferencing a NULL-pointer here but
from the trace it looks like it thinks macro and a previously nullified
profile->macros are the same. They aren't, macro was just allocated here and
shouldn't be NULL if we get here.
Anyway, add an assert and move on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure that the index we pass into long_clear_bit is never higher than the
number of bits in the single long we use as array here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Simply abort if the macro value is bad, that's a libratbag bug and should
never happen.
Found in #312
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Checks for the three layers we need and that any buttons in the files are
consecutive and have the right layers
Fixes#196
Co-authored-by: Jente Hidskes <hjdskes@gmail.com>
We keep the hardcoded fallback.svg for the test device, otherwise we get an
error every time we start ratbagd.devel
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This SVG is generic enough to cover 7-button mice with up to 3 LEDs that are
supported but don't have an SVG. The SVG style is intentionally NOT a generic
mouse to make it obvious that something isn't right here. If we use a generic
mouse, people may not put the effort into a proper SVG style because the
generic mouse is good enough.
The fallback is currently only used for test devices
Some devices can have a custom name, so let's export that capability.
In ratbagd, libratbag/ratbag_profile_set_name() returns an error, we
put it under silence, the client has to check for the capabilities
before asking ratbagd to change the profile name.
Fixes: #266
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The hwdb was a quick and easy way to add entries for new devices but we need
more and more info about the various types of devices. It's better to move
this to a proper database.
Side-effect: this also gives us an easy way to point to the list of devices
supported and makes checking for e.g. missing svgs easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have autodetection for Logitech, but let's always specify the driver for
devices we have in the hwdb.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
d="m -268.43146,403.53037 c -1.07689,19.01234 -1.64984,38.40264 -3.69907,56.68573 -2.36798,4.75208 -4.96718,7.8857 -7.59809,10.79728 h -13.59657 l 5.59859,-67.18309 z"
d="m -390.51793,495.35976 13.14911,20.077 h 24.31724 l -19.22802,-64.1898 -26.14665,-13.56354 -26.14819,13.56354 -19.22802,64.1898 h 24.31879 l 13.14909,-20.077 z"
d="m -408.76059,297.49061 c -14.10207,2.39851 -28.95919,4.88556 -42.94836,0.51186 -20.52977,14.9081 -42.9383,27.51676 -67.08004,35.5287 -1.79569,18.70085 -2.21232,37.56904 -1.4629,56.27529 14.36611,10.46486 18.14376,29.44442 18.67596,46.17572 1.42879,19.10333 3.31403,38.21183 4.78767,57.33922 l 94.06329,0.0603 v -99.67829 h -5.64129 c -1.42556,0 -2.57322,-1.14766 -2.57322,-2.57323 v -54.37631 c 0,-1.42556 1.14766,-2.57322 2.57322,-2.57322 h 2.21136 c -2.89117,-5.43908 -2.75569,-17.98166 -2.75569,-23.06002 0,-6.57742 0.14421,-9.08623 0.15,-13.63002 z"
d="m -398.42702,334.8881 -2.54284,4.40528 -2.54281,4.40266 h 2.90008 v 9.31229 l 2.18557,-1.2609 2.18556,1.2609 v -9.31229 h 2.90008 l -2.54283,-4.40266 z"
d="m 565.3497,594.30093 -2.97509,5.1541 -2.97505,5.15104 h 3.39305 v 10.89527 l 2.55709,-1.47523 2.55708,1.47523 v -10.89527 h 3.39306 l -2.97509,-5.15104 z"
id="path4556"
inkscape:connector-curvature="0"/>
<path
id="use4558"
d="m 565.3497,667.41248 -2.97509,-5.15413 -2.97505,-5.15105 h 3.39305 v -10.89527 l 2.55709,1.47523 2.55708,-1.47523 v 10.89527 h 3.39305 l -2.97508,5.15105 z"
d="m -295.16094,608.46281 6.625,27.125 27.125,5.875 c 0,0 38.75,14.5 45.75,29.125 l 5.5,0.875 2.375,-4.625 c 0,0 -13.875,-23.75 -49.625,-33.375 l -1,-1.25 2.25,-11.25 z"
d="m -386.31433,498.06271 -5.65686,48.08326 c 45.99186,2.07336 100.55399,7.85718 167.23075,21.21321 l 1.06066,3.0052 c 23.24045,-1.15617 46.44002,-2.32824 77.95852,-0.26516 l 3.35876,3.62392 -10.6066,-78.48885 c -119.63944,-15.8417 -179.55343,-5.16228 -233.34523,2.82842 z"
d="m 537.54283,592.59247 5.47684,3.16138 5.47357,3.16133 v -3.60551 h 11.57746 l -1.5676,-2.7172 1.5676,-2.7172 h -11.57746 v -3.60549 l -5.47357,3.16135 z"
d="m 560.07072,647.75385 -5.47685,3.16137 -5.47357,3.16132 v -3.60549 h -11.57747 l 1.56762,-2.7172 -1.56762,-2.71719 h 11.57747 v -3.60551 l 5.47357,3.16136 z"
d="m 77.484288,103.8942 0.485337,-6.617983 c 8.461322,-0.795948 19.932848,-1.405469 31.644865,-2.832276 l -0.13147,6.093759 c -2.00828,2.01378 -25.087068,3.75167 -31.998732,3.35649 z"
d="m 78.284745,97.100947 c 0.680588,-14.4694 3.333553,-29.668628 5.470204,-44.347429 l 0.889389,-0.176348 c -2.502774,14.715793 -5.552664,34.507894 -5.612737,44.100552 z"
d="m 156.02856,154.56715 -0.83645,1.44908 -0.83644,1.44822 h 0.95396 v 3.0632 l 0.71893,-0.41476 0.71892,0.41476 v -3.0632 h 0.95396 l -0.83644,-1.44822 z"
d="m 156.02855,175.12243 -0.83645,-1.44908 -0.83643,-1.44822 h 0.95394 v -3.06321 l 0.71893,0.41477 0.71892,-0.41477 v 3.06321 h 0.95396 l -0.83645,1.44822 z"
d="m 270.88842,559.80819 26.12051,4.09732 62.14289,-30.90074 c 11.97455,-20.17142 5.93562,-23.53024 5.29239,-31.92505 l -91.50713,47.4608 c -3.16993,2.58552 -6.42443,5.13123 -2.04866,11.26767 z"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.