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>
This is the physical description of the button, so there's a distinct
difference between the two, even when the logical action is the same.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move the struct declarations together (and move ratbag_device to the ratbag
device page), have the defgroup tags at the top of the file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
profile was already dereferenced earlier in the function and cannot
be null anyway from the current callers of the function.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
If we goto err early then both dev and drv_data will contain
garbage values. We free one and dereference the other. Let's
null them and add proper checks.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
separate x/y resolution -> check!
has_capability for resolution -> check!
sensitivity -> new item
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It is a common pattern to have:
ratbag_resolution_init(...)
profile->resolution.modes[i].xxx = yyy;
ratbag_resolution_set_cap(&profile->resolution.modes[i], zzz)
So instead of dealing with the internal fields of profile/resolution/modes,
just return the resolution that has been initialized.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
In the end, we just ignore the sensitivity setting.
On the Etekcity, it looks like it is ignored by the mouse, or
maybe the Windows software just messes things up and should
not update the per-axis dpi when playing with sensitivity.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Currently only the hooks for x/y resolution, the rest is unimplemented. Also
the etekcity driver needs an update here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, this is in preparation for the future to make
replacing bits a bit easier - hopefully we only have to change the macro and
not every element then.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The one mode may be disabled and not configurable, but it's still more
predictable to have one that none.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Long-term we should have probe() and read_profile(), the latter of which
should read each profile and fill in _all_ information.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
