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