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>
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.
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>
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
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>
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>
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
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>
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>
