summaryrefslogtreecommitdiff
path: root/src/libsystemd-terminal/idev.h
AgeCommit message (Collapse)Author
2015-07-27terminal: drop unfinished codeDavid Herrmann
This drops the libsystemd-terminal and systemd-consoled code for various reasons: * It's been sitting there unfinished for over a year now and won't get finished any time soon. * Since its initial creation, several parts need significant rework: The input handling should be replaced with the now commonly used libinput, the drm accessors should coordinate the handling of mode-object hotplugging (including split connectors) with other DRM users, and the internal library users should be converted to sd-device and friends. * There is still significant kernel work required before sd-console is really useful. This includes, but is not limited to, simpledrm and drmlog. * The authority daemon is needed before all this code can be used for real. And this will definitely take a lot more time to get done as no-one else is currently working on this, but me. * kdbus maintenance has taken up way more time than I thought and it has much higher priority. I don't see me spending much time on the terminal code in the near future. If anyone intends to hack on this, please feel free to contact me. I'll gladly help you out with any issues. Once kdbus and authorityd are finished (whenever that will be..) I'll definitely pick this up again. But until then, lets reduce compile times and maintenance efforts on this code and drop it for now.
2015-05-30terminal: fix include orderingThomas Hindoe Paaboel Andersen
2015-02-23remove unused includesThomas Hindoe Paaboel Andersen
This patch removes includes that are not used. The removals were found with include-what-you-use which checks if any of the symbols from a header is in use.
2014-10-05terminal/idev: don't remove consumed-mods from kbd-matchesDavid Herrmann
XKB consumed mods include modifiers that *didn't* affect the translation, but might affect it if used. This is very misleading, given that we are usually not interested in that information. Therefore, keep them in real mods to behave like X11 does. Maybe at some point, XKB introduces proper shortcut matching... Also make evcat display consumed modifiers so we can better debug those situations.
2014-10-03terminal/idev: add helper to match keyboard shortcutsDavid Herrmann
Matching keyboard shortcuts on internationalized keyboards is actually non-trivial. Matching the actual key is easy, but the modifiers can be used by both, the matching and the translation step. Therefore, XKB exports "consumed-modifiers" that we use to figure out whether a modifier was already used by the translation step. The new IDEV_KBDMATCH() helper can be used to match on any keyboard shortcut and it will do the right thing.
2014-08-27terminal: add xkb-based keyboard devices to idevDavid Herrmann
The idev-keyboard object provides keyboard devices to the idev interface. It uses libxkbcommon to provide proper keymap support. So far, the keyboard implementation is pretty straightforward with one keyboard device per matching evdev element. We feed everything into the system keymap and provide proper high-level keyboard events to the application. Compose-features and IM need to be added later.
2014-08-27terminal: add evdev elements to idevDavid Herrmann
The evdev-element provides linux evdev interfaces as idev-elements. This way, all real input hardware devices on linux can be used with the idev interface. We use libevdev to interface with the kernel. It's a simple wrapper library around the kernel evdev API that takes care to resync devices after kernel-queue overflows, which is a rather non-trivial task. Furthermore, it's a well tested interface used by all other major input users (Xorg, weston, libinput, ...). Last but not least, it provides nice keycode to keyname lookup tables (and vice versa), which is really nice for debugging input problems.
2014-08-27terminal: add input interfaceDavid Herrmann
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.