Fetching contributors…
Cannot retrieve contributors at this time
59 lines (46 sloc) 2.3 KB
some mice have a per axis "sensitivity" control which adapts the hardware
resolution without changing the DPI (looking at you Etekcity and Roccat).
buttons need a couple of has_capability() functions to check which action
types and actions are possible
profiles should be allowed to be enabled/disabled
light support:
- on/off
- color
- patterns
some epollfd-like thing for the caller to check if events are available.
Needed for notification when the mouse changes through someone else
manipulating settings.
This is on backburner for now, it'll make the library more complicated,
require HID parsing in libratbag for relatively little benefit. The only
advantage we really get out of it is that a configuration UI would be able
to update itself if a user presses a button to e.g. change the profile while
the UI is running.
We should actually drop the "key" functionality in favor of macros:
- either a device supports real hardware macro, then there is no point in
having a special set of keys exported to the user space while the driver
can just figure out which way is most efficient
- if the device does not support macros, then all of the supported keys
should be RATBAG_SPECIAL, so the UI can enumerate them and get a capability
on the current button if it supports this particular action (example:
the UI is interested in sending "Volume Up", not KEY_VOLUMEUP.
Macro support:
- enhance doctext
- add API support for name/groups
- revamp the API?
decide on a stable set of arguments, build the installed version of the
command with that set, add a set of debug arguments (e.g. the
etekcity-specific ones) only available in the build.
interactive shell mode/batch mode for ratbag-command?
dbus proxy - allows parallel access to the devices without interference, and
provides a single instance for root permissions. this should be a separate
change the API to return enum ratbag_error with more meaningful error
messages. errno's are fine internally between the driver, but for the
public-facing API we need better options
- add checks for user input: negative indices, unterminated macro
sequences, excessive timeouts, etc
- add man page
- extend test cases, have a list of test cases that should work on a
specific device, as per-device separate scripts
- add default set/get to profile, resolution