Nothing special about 1000, 256 checks the 2-byte boundary and beyond that
we're just testing whether the computer can count. Let's assume it can.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And change some to drop all parent refs before we even test the struct we want
to test. This way we're more likely to blow up during the test too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code has the profile ref the device, but the device has no back-ref to
the profile. The following code will free the profile from underneath the
client, despite the caller still having a valid ref:
p = ratbag_device_get_profile_by_index(device, 0);
ratbag_profile_ref(p);
ratbag_device_unref(device);
Fix this by not using refs internally. After probe, the device is static
anyway, so the various refs internally aren't needed. Instead, we also ref/unref
the parent struct whenever we ref/unref a struct. Thus, whenevever the device
refcount reaches zero, we know the caller has no ref active.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device has missing profiles, profile will be null and we will
have a segfault.
Better say that the device failed the sanity check.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Two components are added here: a test driver that takes a struct
ratbag_test_device and sets that device up as a ratbag device.
That device is returned to the tests and then checked for sanity.
The ratbag_device_new_test_device() requires the environment variable
RATBAG_TEST set, otherwise we abort. It's also 'hidden' in a separate source
file, so it won't show up in doxygen. And if the test are disabled, this
function does nothing and the test driver never gets registered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The client-exposed API requires a valid device, but internally we can handle
NULL - this way we can hook up the test suite easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the anchor of the text is on the left but the leader on the right,
there will be artefacts when changing the name. Make sure all of the
labels are prooperly set.
This forced us to also relocate the labels on the G500s and the etekcity
scroll alpha.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The etekcity seems to use the last profile as default. The G500s apparently
always comes up with the same profile but it's unclear if it's changeable.
This function may need to be removed later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let's not pretend we will handle out-of-memory errors correctly, and really,
it's not something we really need to be worried about.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We do not check dev for null in any of the other functions. If it
was actually null then we would also already have got a null pointer
dereference earlier in the function.
Or it leads to interesting errors when adding fields to the table
of supported devices.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This should never happen on the Etekcity Scroll Alpha, but we might end
up in a situation where this is required.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Still a mystery of what it is. Though I know how to get/set it, so let's
make it public until somebody claims what it is.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Otherwise the symbol leak test won't recognize it and fails. It's not worth
hacking up that test to avoid implementing those few, so just write them out
instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
etekcity suppports macros already, the other two don't. hidpp10 doesn't
support any write stuff but let's claim we do anyway.
The driver hook for this isn't ideal, read_button is called during init but
we should set all this up during probe and then use read_button exclusively to
update the button, not set the capabilities as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
