handling input events

[catfact]

need to add usb hotplugging (see #11), which means udev. a basic example, works for me to see plug/unplug events from grid: https://gist.github.com/catfact/5ec9ce9af77c0185c88026c52f38b98d

so while we're at it, we could also add libevdev to get arbitrary hid data. a basic example, works for me to read joystick: https://github.com/catfact/kit/blob/master/hid/libevdev/main.c

libevdev gets us partly away from requiring SDL, the other part is replacing the event queue

[catfact]

hotplug is added in PR #23

[catfact]

event queue is rewritten in PR #24. this is just a basic posix queue driven by mutexes and condition variables, no asynchronous messaging system.

[catfact]

i am wondering exactly how to organize input events. in our case that mostly means HID events, but it could include other things (say, the appearance or disappearance of network devices.)

the way usb monitoring is set up so far, we get a "device added" event every time a new node shows up in /dev/inputs/eventX.

libevdev can query the new node to see what kind of events it supports. there are more devices and more events than one might think; for example on my thinkpad, there are separate nodes for the builtin keyboard, media keys, lid switch, power button, touchpad (which sends absolute position), track pointer(which sends relative position, like a mouse), HID devices connected by USB, &c.

in addition there are event nodes that track things like changes to the video bus (when a display device is added), headphone jack plugged/unplugged, &c.

---

anyways, the question is: when a device is discovered (either by hotplugging or scan at startup), what to do with it: decide if a "device added" event should be posted to lua, and if the event node should be polled for input events.

i think it should be easy enough to filter only event nodes with a parent in the usb subsystem, if we want. that's step one.

in usb monitor/scan functions, i'm simply using regex searches to identify e.g. monome devices just by their device path. i propose to extend this so that regex patterns are specified in the configuration file (which doesn't exist yet, but that's another issue...) this would let us exclude event nodes that are always present and we don't want to attach to lua.

then, i'd propose a relatively simple and transparent system for mapping devices and events. on device detection, libevdev can generate a report including:

• device name (e.g. "SINO WEALTH USB KEYBOARD" 😉 )
• a numerical identifer (e.g. VID + PID + counter)
• a nested list of event codes (KEY_SPACE, REL_X, &c), sorted by type:
  • EV_KEY, EV_ABS, EV_REL types for input
  • EV_LED, others? for output

all this can be sent to lua on device addition. on device removal, just send the device ID.

on reception of an event, trigger a lua function like input_event(device_id, event_type, event_code).

lua scripts then have the freedom to decide how to map input devices to internal functions:

• watch for device that support particular event codes; e.g. a joystick_button lua function will be mapped whenever a device supports EV_KEY:BTN_SELECT, BTN_START, and joystick_axis for EV_ABS:ABS_X, ABS_Y, and so on.

• define some generic input functions, attempt to map them to whatever device shows up that supports appropriate event types; e.g. input_key(dev, code) for any EV_KEY events, input_abs(dev, code) for EV_ABS, input_rel(dev, code) for EV_REL, and so on.

• some other scheme, using files for persistent mappings or whatever.

let me know any thoughts. i'll start building out the infrastructure, API details can change as needed.

[catfact]

PR #27 provides the infrastructure.

[catfact]

infrastructure seems ok so i am closing this for now, pending specific issues