libratbag

• library for configurable mice
• generic API for different HW vendors

• completely implemented in userspace

• why "libratbag"? cf. marketing 101

Where it all started

• You spent 100 bucks on a mouse

Implementation

Kernel or User-space?

• kernel already has HID parsing, but
• exposing a complex API through sysfs is ugly
• everything is handled by the HW anyway
• no events handling

Implementation

http://github.com/libratbag/libratbag

What happens when you take a kernel guy and a user-space guy to make a lib?

Implementation

Two parts: external API and HW driver backend

• Logitech HID++ 1.0 (partial)
  • G5
  • G500s
• Logitech HID++ 2.0 (partial)
  • MX Master
  • T650
  • G303 (WIP)
• Etekcity Scroll Alpha
• Roccat Kone XTD

Implementation

struct ratbag *ctx = ratbag_new(...);
struct ratbag_device *device = ratbag_device_new_from_udev(ctx, udev_device);
struct ratbag_profile *p0 = ratbag_device_get_profile(device, 0);
struct ratbag_resolution *r2 = ratbag_profile_get_resolution(p0, 2);
struct ratbag_button *b1 = ratbag_profile_get_button(p0, 1);

int dpi = ratbag_resolution_get_dpi(r2);
if (ratbag_button_get_action_type(b1) == RATBAG_ACTION_TYPE_KEY)
   ...

disclaimer: API unstable (v0.0.1)

Helper Tools (as of 2015-09-14)

$ ratbag-command list
$ ratbag-command info /dev/input/event5
$ ratbag-command dpi get /dev/input/event5
$ ratbag-command dpi set 200 /dev/input/event5
$ ratbag-command profile 3 resolution 2 dpi set 200 /dev/input/event5
$ ratbag-command button 2 action set macro \
                 +KEY_ENTER t50 -KEY_ENTER /dev/input/event5

disclaimer: API unstable (v0.0.1)

Demo

prepare to be amazed.

Demo

full disclosure: GUI sitting on a branch, not in master

Future

• desktops integration (of course)
• more hardware support
• dbus proxy?
  • app needs root access
  • allows parallel access to the device
• Python bindings
  • depends on dbus decision
    
    

disclaimer: no animals were harmed during the making of this presentation