terminal: add input interface

The idev-interface provides input drivers for all libsystemd-terminal
based applications. It is split into 4 main objects:
    idev_context: The context object tracks global state of the input
                  interface. This will include data like system-keymaps,
                  xkb contexts and more.
    idev_session: A session serves as controller for a set of devices.
                  Each session on an idev-context is independent of each
                  other. The session is also the main notification object.
                  All events raised via idev are reported through the
                  session interface. Apart of that, the session is a
                  pretty dumb object that just contains devices.
    idev_element: Elements provide real hardware in the idev stack. For
                  each hardware device, one element is added. Elements
                  have no knowledge of higher-level device types, they
                  only provide raw input data to the upper levels. For
                  example, each evdev device is represented by a different
                  element in an idev session.
     idev_device: Devices are objects that the application deals with. An
                  application is usually not interested in elements (and
                  those are hidden to applications), instead, they want
                  high-level input devices like keyboard, touchpads, mice
                  and more. Device are the high-level interface provided
                  by idev. Each device might be fed by a set of elements.
                  Elements drive the device. If elements are removed,
                  devices are destroyed. If elements are added, suitable
                  devices are created.

Applications should monitor the system for sessions and hardware devices.
For each session they want to operate on, they create an idev_session
object and add hardware to that object. The idev interface requires the
application to monitor the system (preferably via sysview_*, but not
required) for hardware devices. Whenever hardware is added to the idev
session, new devices *might* be created. The relationship between hardware
and high-level idev-devices is hidden in the idev-session and not exposed.

Internally, the idev elements and devices are virtual objects. Each real
hardware and device type inherits those virtual objects and provides real
elements and devices. Those types will be added in follow-up commits.

Data flow from hardware to the application is done via idev_*_feed()
functions. Data flow from applications to hardware is done via
idev_*_feedback() functions. Feedback is usually used for LEDs, FF and
similar operations.

0 files changed, 0 insertions, 0 deletions