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>
And the same for set_active_profile -> set_active. This API is more reliable,
the previous incarnation required the client to compare pointer values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When we read the profiles, we need to know the capabilities of the device.
If the device has not been enumerated, then we are screwed.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
given that we create all the buttons and profiles during probe(), there
is no need to re-probe for it every time we access it.
Right now, this works because only ratbag-command uses the library and
is a one shot program.
In the future, we should also read the events to detect changes in the
configuration if the user can use physical buttons to change the profile,
dpi or something else.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Still not hooked up in the library, but re-assigning back a different
hard-coded macro works.
This also re-introduce the dependency on libevdev for the lib.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
the current driver API is not good enough. We should be able to say
which DPI setting we want to change. Thus, the external API is not
correct either.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It felt weird reading:
Profile 2
Resolutions:
3: 1000dpi @ 500Hz (active)
3: 1600dpi @ 500Hz
3: 2400dpi @ 500Hz
3: 3200dpi @ 500Hz
3: 4000dpi @ 500Hz
3: 8000dpi @ 500Hz
We could index the profiles to 1 too, but that would introduce slightly
more code change.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We need to store the profile in each ratbag_resolution or we will not be
able to get back to the driver.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The devices we're dealing with all have multiple DPIs to configure. This API
will replace the current ratbag_profile_set_resolution_dpi() and friends.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
