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.
2014-08-27 20:17:27 +04:00
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
/***
This file is part of systemd .
Copyright ( C ) 2014 David Herrmann < dh . herrmann @ gmail . com >
systemd is free software ; you can redistribute it and / or modify it
under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation ; either version 2.1 of the License , or
( at your option ) any later version .
systemd is distributed in the hope that it will be useful , but
WITHOUT ANY WARRANTY ; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the GNU
Lesser General Public License for more details .
You should have received a copy of the GNU Lesser General Public License
along with systemd ; If not , see < http : //www.gnu.org/licenses/>.
* * */
/*
* IDev
*/
# pragma once
# include <inttypes.h>
2014-08-27 20:31:34 +04:00
# include <libudev.h>
# include <linux/input.h>
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.
2014-08-27 20:17:27 +04:00
# include <stdbool.h>
# include <stdlib.h>
# include <systemd/sd-bus.h>
# include <systemd/sd-event.h>
2014-08-27 20:34:55 +04:00
# include <xkbcommon/xkbcommon.h>
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.
2014-08-27 20:17:27 +04:00
# include "util.h"
typedef struct idev_data idev_data ;
2014-08-27 20:31:34 +04:00
typedef struct idev_data_evdev idev_data_evdev ;
2014-08-27 20:34:55 +04:00
typedef struct idev_data_keyboard idev_data_keyboard ;
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.
2014-08-27 20:17:27 +04:00
typedef struct idev_event idev_event ;
typedef struct idev_device idev_device ;
typedef struct idev_session idev_session ;
typedef struct idev_context idev_context ;
/*
* Types
*/
enum {
2014-08-27 20:31:34 +04:00
IDEV_ELEMENT_EVDEV ,
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.
2014-08-27 20:17:27 +04:00
IDEV_ELEMENT_CNT
} ;
enum {
2014-08-27 20:34:55 +04:00
IDEV_DEVICE_KEYBOARD ,
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.
2014-08-27 20:17:27 +04:00
IDEV_DEVICE_CNT
} ;
2014-08-27 20:31:34 +04:00
/*
* Evdev Elements
*/
struct idev_data_evdev {
struct input_event event ;
} ;
2014-08-27 20:34:55 +04:00
/*
* Keyboard Devices
*/
struct xkb_state ;
enum {
IDEV_KBDMOD_IDX_SHIFT ,
IDEV_KBDMOD_IDX_CTRL ,
IDEV_KBDMOD_IDX_ALT ,
IDEV_KBDMOD_IDX_LINUX ,
IDEV_KBDMOD_IDX_CAPS ,
IDEV_KBDMOD_CNT ,
IDEV_KBDMOD_SHIFT = 1 < < IDEV_KBDMOD_IDX_SHIFT ,
IDEV_KBDMOD_CTRL = 1 < < IDEV_KBDMOD_IDX_CTRL ,
IDEV_KBDMOD_ALT = 1 < < IDEV_KBDMOD_IDX_ALT ,
IDEV_KBDMOD_LINUX = 1 < < IDEV_KBDMOD_IDX_LINUX ,
IDEV_KBDMOD_CAPS = 1 < < IDEV_KBDMOD_IDX_CAPS ,
} ;
enum {
IDEV_KBDLED_IDX_NUM ,
IDEV_KBDLED_IDX_CAPS ,
IDEV_KBDLED_IDX_SCROLL ,
IDEV_KBDLED_CNT ,
IDEV_KBDLED_NUM = 1 < < IDEV_KBDLED_IDX_NUM ,
IDEV_KBDLED_CAPS = 1 < < IDEV_KBDLED_IDX_CAPS ,
IDEV_KBDLED_SCROLL = 1 < < IDEV_KBDLED_IDX_SCROLL ,
} ;
struct idev_data_keyboard {
struct xkb_state * xkb_state ;
int8_t ascii ;
uint8_t value ;
uint16_t keycode ;
uint32_t mods ;
uint32_t consumed_mods ;
uint32_t n_syms ;
uint32_t * keysyms ;
uint32_t * codepoints ;
} ;
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.
2014-08-27 20:17:27 +04:00
/*
* Data Packets
*/
enum {
IDEV_DATA_RESYNC ,
2014-08-27 20:31:34 +04:00
IDEV_DATA_EVDEV ,
2014-08-27 20:34:55 +04:00
IDEV_DATA_KEYBOARD ,
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.
2014-08-27 20:17:27 +04:00
IDEV_DATA_CNT
} ;
struct idev_data {
unsigned int type ;
bool resync : 1 ;
2014-08-27 20:31:34 +04:00
union {
idev_data_evdev evdev ;
2014-08-27 20:34:55 +04:00
idev_data_keyboard keyboard ;
2014-08-27 20:31:34 +04:00
} ;
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.
2014-08-27 20:17:27 +04:00
} ;
/*
* Events
*/
enum {
IDEV_EVENT_DEVICE_ADD ,
IDEV_EVENT_DEVICE_REMOVE ,
IDEV_EVENT_DEVICE_DATA ,
IDEV_EVENT_CNT
} ;
struct idev_event {
unsigned int type ;
union {
struct {
idev_device * device ;
} device_add , device_remove ;
struct {
idev_device * device ;
idev_data data ;
} device_data ;
} ;
} ;
typedef int ( * idev_event_fn ) ( idev_session * s , void * userdata , idev_event * ev ) ;
/*
* Devices
*/
void idev_device_enable ( idev_device * d ) ;
void idev_device_disable ( idev_device * d ) ;
/*
* Sessions
*/
enum {
IDEV_SESSION_CUSTOM = ( 1 < < 0 ) ,
IDEV_SESSION_MANAGED = ( 1 < < 1 ) ,
} ;
int idev_session_new ( idev_session * * out ,
idev_context * c ,
unsigned int flags ,
const char * name ,
idev_event_fn event_fn ,
void * userdata ) ;
idev_session * idev_session_free ( idev_session * s ) ;
DEFINE_TRIVIAL_CLEANUP_FUNC ( idev_session * , idev_session_free ) ;
bool idev_session_is_enabled ( idev_session * s ) ;
void idev_session_enable ( idev_session * s ) ;
void idev_session_disable ( idev_session * s ) ;
2014-08-27 20:31:34 +04:00
int idev_session_add_evdev ( idev_session * s , struct udev_device * ud ) ;
int idev_session_remove_evdev ( idev_session * s , struct udev_device * ud ) ;
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.
2014-08-27 20:17:27 +04:00
/*
* Contexts
*/
int idev_context_new ( idev_context * * out , sd_event * event , sd_bus * sysbus ) ;
idev_context * idev_context_ref ( idev_context * c ) ;
idev_context * idev_context_unref ( idev_context * c ) ;
DEFINE_TRIVIAL_CLEANUP_FUNC ( idev_context * , idev_context_unref ) ;