Recent changes to LIRCv2

LIRCv2 modified by Alec Leamas

Alec Leamas — Mon, 08 Dec 2014 08:32:08 -0000

--- v11
+++ v12
@@ -11,14 +11,17 @@
     integration easier.  
   - We need to become more open to be able cooperate with other communities.
   - Create a codebase which is more agile and flexible. 
-  - In the long run, there should be paths to use other redering engines than 
+  - In the long run, there should be paths to use other rendering engines than 
     current which is showing it's age.

 Basic concepts for a new design:
 --------------------------------
   - We should be provide the same socket interface as current lircd w r t receiving
-    and sending IR commands. We might drop other, non-documented features.
-  - We should move away from the basic model wiht one lircd process connected
+    and sending IR commands. We might drop other, non-documented features. This is 
+    about keeping the application support.
+  - We should keep the driver interface. Keeping a stable ground for devs to integrate
+    new hardware is essential.
+  - We should move away from the basic model with one lircd process connected
     to one socket to a model where several lircd instances possibly are connected 
     to a single socket. 
   - Rather than to enhance the already complicated lircd process we should try to 
@@ -48,7 +51,7 @@
     in the manual ("Writing applications for LIRC.")
   - An API built on top of the socket interface providing the functions described in
     the manual ("The lirc_client API").
-  - Code which either gets input from  or send data to a remote lircd
+  - Code which either gets input from  or sends data to a remote lircd
     instance over the network (the "--listen" and "--connect" runtime options).
   - Code which send all received data to the kernel uinput device, implementing the
     --uinput runtime opiton. 
@@ -66,17 +69,6 @@
   - The easiest way to handle remotes not supported by the kernel, attracting developers
     and power users.
   - Added functionality compared to the kernel device interface attracting applications.
-
-Limiting factors.
------------------
-  - Old, complex and more or less undocumented code – hard to maintain. If 
-    possible, don't add more functions to the core lircd daemon.
-  - Keep the application interface. This is the primary reason LIRC is used.
-  - Keep the driver interface. Keeping a stable ground for devs to integrate
-    new hardware is essential.
-  - In particular, we need to keep the socket interface around, even if we might 
-    declare it as deprecated now when the sending API is in place (seems that when 
-    it's used, it's for sending).

 Why dbus:
 ---------
@@ -106,9 +98,9 @@
     listening to/sending IR commands.
   - Client connects to lircd either
       + Directly to the socket to send data.
-      + Indirectly to the socket using the LIRC API.
+      + Indirectly to the socket using the LIRC API to listen or send.
       + Directly to the Dbus interface to listen or send.
-  - The TCP module is full duplex module reading from the remote lircd instance
+  - The TCP module is a full duplex module reading from the remote lircd instance
     providing data on dbus in the same way as a "normal" lircd instance,
     implementing the runtime --listen and --connect options.
   - The uinput module listens to dbus IR events a feeds them to the kernel
@@ -123,7 +115,7 @@
     means that we have a framework where we can test different implementations. We now 
     need a new name for the kernel device/dbus thing. Let's call it 'connector'. Our
     first connector will be a stripped down lircd. However, we should design this so
-    a that a we could use something enterely different later.
+    that we could use something enterely different later.
   - We need a new Manager module which loads/unloads correct connector + configuration when 
     configuration changes or udev signals devices are removed/added. This exposes the primary
     Dbus client interface, since it's the only instance with a given name which always exists.

LIRCv2 modified by Alec Leamas

Alec Leamas — Mon, 08 Dec 2014 04:33:14 -0000

--- v10
+++ v11
@@ -1,19 +1,66 @@
-Why revise design
+This page is about redesigning lircd to a number smaller components. Other tools e. g., irrecord is not affected.
+
+
+Why revise design?
 ------------------
 In order to stay relevant, we need to modernize lirc:

   - To handle multiple input/output devices. 
   - To handle hotplugging of new devices.
   - To add a modern, event-driven interface to make future application 
-    integration easier.
-  - Create a codebase which is more agile and flexible. Open up for other rendering 
-    implementations.
+    integration easier.  
+  - We need to become more open to be able cooperate with other communities.
+  - Create a codebase which is more agile and flexible. 
+  - In the long run, there should be paths to use other redering engines than 
+    current which is showing it's age.
+
+Basic concepts for a new design:
+--------------------------------
+  - We should be provide the same socket interface as current lircd w r t receiving
+    and sending IR commands. We might drop other, non-documented features.
+  - We should move away from the basic model wiht one lircd process connected
+    to one socket to a model where several lircd instances possibly are connected 
+    to a single socket. 
+  - Rather than to enhance the already complicated lircd process we should try to 
+    split it into smaller pieces with well-defined interfaces.
+  - The synchronization now performed in the lircd main loop should if possible
+    be delegated to some existing mechanism. This is the glue that connects all the 
+    lircd current functionality to one, single piece of tightly coupled code.
+
+What is lircd?
+--------------
+In order  to create a new design for lircd, we need to understand the basic blocks in 
+current code:
+
+  - The core is IR decoding/encoding. There are really no well-defined interfaces to this.
+    Basic concepts here is "IR commands", the user level representation of a remote
+    button press and the low-level IR data.
+      + When sending, lircd converts IR commmands to a sequence of low-level IR data
+        using the database, usually in /etc/lircd.conf and/or /etc/lircd.conf.d/.
+      + When receiving, lircd converts the low-level IR data to IR commands using the
+        same database.
+  - A driver adapter which can  load and use a device-specific user-space driver. 
+    Drivers have an established API to lircd.
+  - A socket interface which allows:
+      + Listening to keypresses from remote.
+      + Sending of IR commands.
+  - A command handling interface implementing the socket commands. This interface is described
+    in the manual ("Writing applications for LIRC.")
+  - An API built on top of the socket interface providing the functions described in
+    the manual ("The lirc_client API").
+  - Code which either gets input from  or send data to a remote lircd
+    instance over the network (the "--listen" and "--connect" runtime options).
+  - Code which send all received data to the kernel uinput device, implementing the
+    --uinput runtime opiton. 
+  - A main loop which handles both static parties (data from the kernel device, 
+    data from the socket interface, possibly TCP data) and dynamically connected 
+    socket clients.

 Why LIRC?
 ---------
-If we change the overall design, we need to be careful not harm LIRC's strong points:
+If we change the overall design, we need to be careful not to harm LIRC's strong points:

-  - Strong application support in the Linux HTPC area..
+  - The strong application support in the Linux HTPC area..
   - The only framework for handling IR remotes available in all Linux distros 
     (besides the kernel).
   - The easiest way to handle remotes not supported by the kernel, attracting developers
@@ -26,7 +73,7 @@
     possible, don't add more functions to the core lircd daemon.
   - Keep the application interface. This is the primary reason LIRC is used.
   - Keep the driver interface. Keeping a stable ground for devs to integrate
-    new hardware is esssential.
+    new hardware is essential.
   - In particular, we need to keep the socket interface around, even if we might 
     declare it as deprecated now when the sending API is in place (seems that when 
     it's used, it's for sending).
@@ -45,37 +92,38 @@
     become part of the kernel(kdbus). There is also an OSX port.
   - The asynchronous, message based design fits the LIRC bill.

-What is lircd, BTW:
--------------------
-In order  to create a new design for lircd, we need to understand the basic blocks in 
-current code:
-
-  - The core is IR decoding/encoding.
-  - A driver adapter which can  load and use a device-specific driver.
-  - A command handling interface implementing the socket commands
-  - A main loop which handles both static parties (data from the kernel device, 
-    data from the socket interface, possibly TCP data) and dynamically connected 
-    socket clients.

 A new design
 ------------
-  - Use Dbus as dispatcher. All components and clients connects to to the bus which 
-    passes messages and synchronizes. 
+  - Use Dbus as dispatcher. All components and clients connects to the bus which 
+    passes messages and synchronizes. The only synchronization done within lircd is
+    the full duplex send/receive conflict on the kernel device. This means that
+    components are defined by their dbus interface.
   - Limit current lircd to 
       + Decoding of data from kernel which are broadcasted as dbus events.
       + Handling dbus commands, notably for sending.
-      + Exposes a Dbus interface for above.
-  - Move lircd command decoding/encoding, dynamic clients, TCP and uinput code to 
-    separate modules connected to Dbus.
+    Practically, this means that lircd exposes a dbus interface supporting 
+    listening to/sending IR commands.
+  - Client connects to lircd either
+      + Directly to the socket to send data.
+      + Indirectly to the socket using the LIRC API.
+      + Directly to the Dbus interface to listen or send.
+  - The TCP module is full duplex module reading from the remote lircd instance
+    providing data on dbus in the same way as a "normal" lircd instance,
+    implementing the runtime --listen and --connect options.
+  - The uinput module listens to dbus IR events a feeds them to the kernel
+    uinput device, implementing the --uinput runtime option.
   - The socket interface + command handling is a separate module handling dbus-socket 
     conversion. Each connected client is a separate process, dbus handles 
     synchronization.
   - We can now start several lircd input instances, all connected to same dbus and 
-    socket interface -> solves multiple input devices.
+    socket interface -> solves multiple input devices. In other configurations we
+    use different sockets as today.
   - The lircd instance is only defined by the dbus and kernel device interface. This 
     means that we have a framework where we can test different implementations. We now 
     need a new name for the kernel device/dbus thing. Let's call it 'connector'. Our
-    first connector will be a stripped down lircd.
+    first connector will be a stripped down lircd. However, we should design this so
+    a that a we could use something enterely different later.
   - We need a new Manager module which loads/unloads correct connector + configuration when 
     configuration changes or udev signals devices are removed/added. This exposes the primary
     Dbus client interface, since it's the only instance with a given name which always exists.

LIRCv2 modified by Alec Leamas

Alec Leamas — Sun, 07 Dec 2014 09:44:01 -0000

--- v9
+++ v10
@@ -83,5 +83,9 @@
     do this in a more or less implementation-agnostic way. First shot is that a 
     configuration is a dictionary of strings, a YAML or xml file or something similar.

+Like this ![Design sketch](http://leamas.fedorapeople.org/lirc/v2/design.png)

-Like this ![Design sketch](http://leamas.fedorapeople.org/lirc/v2/design.png)
+Harctoolbox notes
+-----------------
+
+There are some [thoughts](http://www.harctoolbox.org/architecture.html) on the same topic with a different perspective. In this parlance, a connector is basically a combined listener/sender with a Dbus interface.

LIRCv2 modified by Alec Leamas

Alec Leamas — Sat, 06 Dec 2014 22:30:49 -0000

--- v8
+++ v9
@@ -76,7 +76,7 @@
     means that we have a framework where we can test different implementations. We now 
     need a new name for the kernel device/dbus thing. Let's call it 'connector'. Our
     first connector will be a stripped down lircd.
-  - We need a new module which loads/unloads correct connector + configuration when 
+  - We need a new Manager module which loads/unloads correct connector + configuration when 
     configuration changes or udev signals devices are removed/added. This exposes the primary
     Dbus client interface, since it's the only instance with a given name which always exists. 
   - The configuration is a little tricky. However, with a little care, we should be able to

LIRCv2 modified by Alec Leamas

Alec Leamas — Sat, 06 Dec 2014 22:27:36 -0000

--- v7
+++ v8
@@ -25,6 +25,8 @@
   - Old, complex and more or less undocumented code – hard to maintain. If 
     possible, don't add more functions to the core lircd daemon.
   - Keep the application interface. This is the primary reason LIRC is used.
+  - Keep the driver interface. Keeping a stable ground for devs to integrate
+    new hardware is esssential.
   - In particular, we need to keep the socket interface around, even if we might 
     declare it as deprecated now when the sending API is in place (seems that when 
     it's used, it's for sending).

LIRCv2 modified by Alec Leamas

Alec Leamas — Sat, 06 Dec 2014 22:05:16 -0000

--- v6
+++ v7
@@ -40,12 +40,13 @@
   - It is language independent with bindings to most languages and the two common 
     main loops (GLib and Qt).
   - It is already part of any Linux system we target. Even more so when it shortly will 
-    become part of the kernel. There is also an OSX port.
+    become part of the kernel(kdbus). There is also an OSX port.
   - The asynchronous, message based design fits the LIRC bill.

 What is lircd, BTW:
 -------------------
-In order  to create a new design for lircd, we need to understand the basic blocks in current code:
+In order  to create a new design for lircd, we need to understand the basic blocks in 
+current code:

   - The core is IR decoding/encoding.
   - A driver adapter which can  load and use a device-specific driver.

LIRCv2 modified by Alec Leamas

Alec Leamas — Sat, 06 Dec 2014 22:03:24 -0000

--- v5
+++ v6
@@ -22,7 +22,7 @@

 Limiting factors.
 -----------------
-  - Old, complex code and more or less undocumented code – hard to maintain. If 
+  - Old, complex and more or less undocumented code – hard to maintain. If 
     possible, don't add more functions to the core lircd daemon.
   - Keep the application interface. This is the primary reason LIRC is used.
   - In particular, we need to keep the socket interface around, even if we might

LIRCv2 modified by Alec Leamas

Alec Leamas — Sat, 06 Dec 2014 22:02:18 -0000

--- v4
+++ v5
@@ -1,6 +1,7 @@
 Why revise design
 ------------------
 In order to stay relevant, we need to modernize lirc:
+
   - To handle multiple input/output devices. 
   - To handle hotplugging of new devices.
   - To add a modern, event-driven interface to make future application 
@@ -11,6 +12,7 @@
 Why LIRC?
 ---------
 If we change the overall design, we need to be careful not harm LIRC's strong points:
+
   - Strong application support in the Linux HTPC area..
   - The only framework for handling IR remotes available in all Linux distros 
     (besides the kernel).
@@ -31,6 +33,7 @@
 ---------
 My idea is that we base a new design on dbus which acts as a dispatcher between multiple 
 clients and multiple lircd instances. There is a number or reasons to use Dbus:
+
   - Dbus solves the problem of passing messages between different users (i. e., the 
     lircd user and the session.)
   - Dbus is fast enough to handle keypresses without user-visible lag (?).
@@ -43,6 +46,7 @@
 What is lircd, BTW:
 -------------------
 In order  to create a new design for lircd, we need to understand the basic blocks in current code:
+
   - The core is IR decoding/encoding.
   - A driver adapter which can  load and use a device-specific driver.
   - A command handling interface implementing the socket commands

LIRCv2 modified by Alec Leamas

Alec Leamas — Sat, 06 Dec 2014 22:01:21 -0000

--- v3
+++ v4
@@ -4,7 +4,7 @@
   - To handle multiple input/output devices. 
   - To handle hotplugging of new devices.
   - To add a modern, event-driven interface to make future application 
-     integration easier.
+    integration easier.
   - Create a codebase which is more agile and flexible. Open up for other rendering 
     implementations.

LIRCv2 modified by Alec Leamas

Alec Leamas — Sat, 06 Dec 2014 22:00:48 -0000

--- v2
+++ v3
@@ -57,18 +57,21 @@
   - Limit current lircd to 
       + Decoding of data from kernel which are broadcasted as dbus events.
       + Handling dbus commands, notably for sending.
+      + Exposes a Dbus interface for above.
   - Move lircd command decoding/encoding, dynamic clients, TCP and uinput code to 
     separate modules connected to Dbus.
   - The socket interface + command handling is a separate module handling dbus-socket 
-    conversion. Each connected client is a separate process (thread?), dbus handles 
+    conversion. Each connected client is a separate process, dbus handles 
     synchronization.
   - We can now start several lircd input instances, all connected to same dbus and 
     socket interface -> solves multiple input devices.
   - The lircd instance is only defined by the dbus and kernel device interface. This 
     means that we have a framework where we can test different implementations. We now 
-    need a new name for the kernel device/dbus thing. Let's call it 'connector' 
+    need a new name for the kernel device/dbus thing. Let's call it 'connector'. Our
+    first connector will be a stripped down lircd.
   - We need a new module which loads/unloads correct connector + configuration when 
-    configuration changes or udev signals devices are removed/added. 
+    configuration changes or udev signals devices are removed/added. This exposes the primary
+    Dbus client interface, since it's the only instance with a given name which always exists. 
   - The configuration is a little tricky. However, with a little care, we should be able to 
     do this in a more or less implementation-agnostic way. First shot is that a 
     configuration is a dictionary of strings, a YAML or xml file or something similar.