forked from drath/libratbag
67 lines
3.0 KiB
Plaintext
67 lines
3.0 KiB
Plaintext
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
|
|
|
|
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?
|
|
- add command to set a macro in ratbag-command
|
|
|
|
ratbag-command needs a revamp of the arguments into a tree type, e.g.
|
|
instead of switch-dpi something like "ratbag command resolution set"
|
|
proposed set of arguments:
|
|
ratbag-command profile 1 resolution 3 dpi set 400
|
|
ratbag-command profile 1 resolution 3 dpi-x set 400
|
|
ratbag-command profile 1 resolution 3 dpi-x get
|
|
ratbag-command profile 1 resolution 3 report-rate get
|
|
"profile" and "resolution" arguments can be optional, we juse the current
|
|
profile where missing, i.e. "ratbag-command dpi get" works
|
|
ratbag-command profile 1 button 1 button set 3
|
|
ratbag-command profile 1 button 1 special set foo
|
|
ratbag-command profile 1 button 1 macro set +KEY_ENTER -KEY_ENTER
|
|
|
|
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 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
|
|
project. Ideally, we can wrap the dbus API into a libratbag-dbus that
|
|
exposes the same API to the application, but goes through dbus.
|
|
|
|
python bindings - depends on the dbus decision, python bindings could be
|
|
wrappers around libratbag itself, or a wrapper around the dbus protocol to
|
|
speak to the dbus daemon
|
|
|
|
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
|