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