Raw codes and toggle bits

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Raw codes and toggle bits

Helen Foster-2
Hi,

As far as I can see in the LIRC manuals, raw codes do not support any
toggling - please correct me if I missed something here!

In theory, toggle bits in raw codes can be described simply by having
two sequences for each button. The Android app "irplus" supports this
when using Pronto Hex codes.

For receiving in LIRC, it is possible to assign two codes for each
command, and make them do the same thing (though it doesn't fit with
the button namespace). This is not an option for sending, because the
toggle bit needs to alternate.

Should LIRC support toggle bits in raw codes, using some "two
sequences for each button" syntax in the raw_codes block?

Regards,
Helen

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raw codes and toggle bits

Bengt Martensson-2
On 07/25/16 14:44, Helen Foster wrote:
> Hi,

Hi Helen,
>
> As far as I can see in the LIRC manuals, raw codes do not support any
> toggling - please correct me if I missed something here!
>...

I think that your understanding is correct. Let me just add that for the
receiving use case, selecting a toggling protocol is a bad choice; just
select a non-toggling protocol/remote to control the computer. For
sending, modern consumer devices are in general no that picky, although
you still may have problems to turn an RC5 TV to channel 11, 22,... But
I have had one device (Vivanco AV Control 5, manufactured by Welkintec
Ltd, using RECS80 codes) that steadfastly refused to act on signals with
the wrong toggle value...)

> Should LIRC support toggle bits in raw codes, using some "two
> sequences for each button" syntax in the raw_codes block?

I assume "should" means "would it be a useful feature".  Lirc is a
software system that was designed around 20 years ago. Since then, we
have learned much more about IR signals. There are many fundamental
problems. You have just addressed one of many design problems with Lirc.
IMHO, it is better to leave Lirc for what it is, and to devote work on a
successor instead.

Greetz,

Bengt


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raw codes and toggle bits

Alec Leamas


On 26/07/16 09:48, Bengt Martensson wrote:
> I assume "should" means "would it be a useful feature".  Lirc is a
> software system that was designed around 20 years ago. Since then, we
> have learned much more about IR signals. There are many fundamental
> problems. You have just addressed one of many design problems with Lirc.
> IMHO, it is better to leave Lirc for what it is, and to devote work on a
> successor instead.
>

Hm... As for the basic encoding/decoding stuff I think this might be the
right way to handle it. To be honest, large parts of this code is still
more or less black magic to me, and very hard to maintain. Of course, I
someone comes up with a patch it will be considered, but that's
basically it.

On the other hand, I think the overall interfaces to lirc are sound
enough to be preserved, and with those the application compatibility in
a wide sense.

I have a sketch for a yet another major split or current lircd to a
separate frontend providing the application interface and one or more
separate backends doing the actual encoding/decoding work. The goals are to

   - Make it possible start-stop backends when new hardware is
attached,  to match the dynamic nature of the current kernel device
management. Current design is really geared to the 20 year old static
kernel.
   - Make it easier to use multiple input units (i. e., backends) seen
as a single stream by applications.
   - Cleanup the core code by delegating some options to separate
backends (e. g., --listen) or tools (--connect).
   - Make the code more testable,
   - Last, but not least, this would make it possible to implement new
backends not using the current representation of the IR data, with
completely new configuration files and partly also tools. I presume
Bengt might have some tricks in his sleeves here ;)

The old backend should probably be available for a long time in parallel.

So, while I think Bengt is right about modifying the current code, I see
paths making it possible to implement features like this ahead. It will
certainly take some time, though.


Cheers!

--alec

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raw codes and toggle bits

Bengt Martensson-2
On 07/27/16 12:31, Alec Leamas wrote:

>
>
> On 26/07/16 09:48, Bengt Martensson wrote:
>> I assume "should" means "would it be a useful feature".  Lirc is a
>> software system that was designed around 20 years ago. Since then, we
>> have learned much more about IR signals. There are many fundamental
>> problems. You have just addressed one of many design problems with Lirc.
>> IMHO, it is better to leave Lirc for what it is, and to devote work on a
>> successor instead.
>>
>
> Hm... As for the basic encoding/decoding stuff I think this might be the
> right way to handle it. To be honest, large parts of this code is still
> more or less black magic to me, and very hard to maintain. Of course, I
> someone comes up with a patch it will be considered, but that's
> basically it.
>
> On the other hand, I think the overall interfaces to lirc are sound
> enough to be preserved, and with those the application compatibility in
> a wide sense.
>
> I have a sketch for a yet another major split or current lircd to a
> separate frontend providing the application interface and one or more
> separate backends doing the actual encoding/decoding work. ...

IMHO, the most important issue in the short/mid time span is to separate
the "event mapping" from the IR engine.  See this article:
http://harctoolbox.org/architecture.html .
Lirc tries to do "everything". This has grown worse the last few years
(kernel decoding, devinput), but has been inherent in Lirc from the
start: All the "Lirccode devices/remotes" do not belong to an IR engine
proper but constitutes an event dispatcher. It would be nice to have a
good event dispatcher that does not disguise itself as an IR program.
Then, an IR receiver is nothing but an event generator, triggered by IR,
see the article.

What I am after is a "component architecture", where the components
(event mapper, IR receiver, IR sender) has well defined interfaces, and
(thus) can be replaced by alternative components. An event mapper should
likely be Linux specific; an IR engine (receiver or sender) should
strive to  be system independant).

I have written most that I have to say in the article. Update: The
"(presently not published) simple dispatcher in Java" is this one:
https://github.com/bengtmartensson/dispatcher

I am not sure if/how Alec's front/backend maps to my terminology.

Greetz,

Bengt

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raw codes and toggle bits

Alec Leamas
In reply to this post by Bengt Martensson-2


On 27/07/16, Bengt Martensson wrote:

> What I am after is a "component architecture", where the components
> (event mapper, IR receiver, IR sender) has well defined interfaces, and
> (thus) can be replaced by alternative components. An event mapper should
> likely be Linux specific; an IR engine (receiver or sender) should
> strive to  be system independant).
>
> I have written most that I have to say in the article. Update: The
> "(presently not published) simple dispatcher in Java" is this one:
> https://github.com/bengtmartensson/dispatcher
>
> I am not sure if/how Alec's front/backend maps to my terminology.
In short, the frontend more or less completely matches the dispatcher.
The backend is a combined listener/sender thing. However, there could be
multiple backends. Stay tuned for now, will push a branch later for
discussion.

Cheers!

--alec


------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Raw codes and toggle bits

Bengt Martensson-2
On 07/29/16 10:17, Alec Leamas wrote:

>
>
> On 27/07/16, Bengt Martensson wrote:
>
>> What I am after is a "component architecture", where the components
>> (event mapper, IR receiver, IR sender) has well defined interfaces, and
>> (thus) can be replaced by alternative components. An event mapper should
>> likely be Linux specific; an IR engine (receiver or sender) should
>> strive to  be system independant).
>>
>> I have written most that I have to say in the article. Update: The
>> "(presently not published) simple dispatcher in Java" is this one:
>> https://github.com/bengtmartensson/dispatcher
>>
>> I am not sure if/how Alec's front/backend maps to my terminology.
> In short, the frontend more or less completely matches the dispatcher.
> The backend is a combined listener/sender thing. However, there could be
> multiple backends. Stay tuned for now, will push a branch later for
> discussion.

Kewl. What is your idea of interprocess communication? Some time ago you
told me (privately) that the Dbus was the best thing since sliced bread,
then you reverted that standpoint
(https://sourceforge.net/p/lirc/tickets/117/) and left my request
("would love to hear your arguments...") unanswered.

I guess that zeroconf comes in somewhere...

PS. Nice to see you back.

Greetz,

Bengt

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

New lircd design (Was: Raw codes and toggle bits)

Alec Leamas
In reply to this post by Alec Leamas
On 29/07/16 10:17, Alec Leamas wrote:

> On 27/07/16, Bengt Martensson wrote:
>>
>> I have written most that I have to say in the article. Update: The
>> "(presently not published) simple dispatcher in Java" is this one:
>> https://github.com/bengtmartensson/dispatcher
>>
>> I am not sure if/how Alec's front/backend maps to my terminology.
> In short, the frontend more or less completely matches the dispatcher.
> The backend is a combined listener/sender thing. However, there could
> be multiple backends. Stay tuned for now, will push a branch later for
> discussion.

I have pushed a WIP branch called ng. It's by no mean functional, just a
preliminary hack. The state could be described as "works occasionally".I
will not be able to work with this for some time, so here are some
comments for those interested (including myself once I return to this):

The basic idea is to split the lircd  monolith to a single frontend
called lircd and one or more backends. The frontend, a k a dispatcher,
preserves the current client interface.

Each component is a separate process, communicating over sockets just as
today.

The main dispatcher lircd.cpp  is in a reasonable shape. It has a file
comment describing what it is doing.

*lircd-backend-tcp* is a simple backend  implementing the --listen
option. It's used to pioneer the backend interface.

*lircd-backend-std* is  the remaining parts of current lircd
implementing a backend. The combination of  lircd + a single
lircd-backend-std should be identical to current lircd.

*irtool* is a new tool aimed to export the complete new control socket
interface. irtool -h gives a hint. It's the only user tool which is
aware of the different backends.

*dummy-backend* is a expect/tcl test tool .

There is no documentation whatsoever. The objectives includes to make it:

     - Easier to respond to hardware changes by starting a backend,
typically in a udev rule.
     - Easier to use multiple devices simultaneously.
     - Possible to re-implement the backend with completely new ir
rendering while still staying API compatible.
     - More testable.


Cheers!

--alec

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Bengt Martensson-2
On 08/11/16 12:06, Alec Leamas wrote:

> On 29/07/16 10:17, Alec Leamas wrote:
>
>> On 27/07/16, Bengt Martensson wrote:
>>>
>>> I have written most that I have to say in the article. Update: The
>>> "(presently not published) simple dispatcher in Java" is this one:
>>> https://github.com/bengtmartensson/dispatcher
>>>
>>> I am not sure if/how Alec's front/backend maps to my terminology.
>> In short, the frontend more or less completely matches the dispatcher.
>> The backend is a combined listener/sender thing. However, there could
>> be multiple backends. Stay tuned for now, will push a branch later for
>> discussion.
>
> I have pushed a WIP branch called ng. It's by no mean functional, just a
> preliminary hack. The state could be described as "works occasionally".I

Appears that you forgot to checkin lircd_commands.h and
backend-commands.h.

Also, what do you say about dumping the named pipes in favor of TCP
sockets (or something else?)? The former are intrinsically non-portable,
and not network transparent.

Still waiting for an explanation why you changed your mind about d-bus
support ;-).

Greetz,

Bengt


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Alec Leamas


On 11/08/16 16:56, Bengt Martensson wrote:
> On 08/11/16 12:06, Alec Leamas wrote:
>> I have pushed a WIP branch called ng. It's by no mean functional, just a
>> preliminary hack. The state could be described as "works occasionally".I
> Appears that you forgot to checkin lircd_commands.h and
> backend-commands.h.
>
>

Oops... fixed.

--alec

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Alec Leamas
In reply to this post by Bengt Martensson-2


On 11/08/16 16:56, Bengt Martensson wrote:
> Also, what do you say about dumping the named pipes in favor of TCP
> sockets (or something else?)? The former are intrinsically non-portable,
> and not network transparent.

Like using a free tcp port? Might be better, indeed. I don't care much
about portability (MacOS certainly can handle these), but network
transparency is an argument.

> Still waiting for an explanation why you changed your mind about d-bus
> support ;-).
>
>
Basically, I have re-evaluated the multiple sockets/poll() approach. It
is existing code, portable and actually really fast. Furthermore, the
kDbus project has been sent back to the design board. I'm not really
sure that userspace dBus has a latency low enough for our purposes.

Also note the intrinsic access problem related to the kernel devices. It
makes sense that backends runs as separate processes, should they need
some privileges. Having separate processes is IMHO also more testable
and robust.

Adding dBus interfaces to lirc still a good thing. But then as a
separate connector, similar to e. g., lircd-uinput or a upcoming
lircd-connect-tcp module  implementing --connect.

Shouldn't say I'm sure about all of this, no way. This is still in an  
early stage...

BTW, while we are on it: What do you think about adding a
"send-binary-data" command to irsend? This is the time we could add such
a command and handle a "not implemented" situation properly as a beginning.

--alec

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Bengt Martensson-2
On 08/11/16 17:55, Alec Leamas wrote:

>
>
> On 11/08/16 16:56, Bengt Martensson wrote:
>> Also, what do you say about dumping the named pipes in favor of TCP
>> sockets (or something else?)? The former are intrinsically non-portable,
>> and not network transparent.
>
> Like using a free tcp port? Might be better, indeed. I don't care much
> about portability (MacOS certainly can handle these), but network
> transparency is an argument.

I think we should deprecate the named pipes/Unix domain sockets and the
/var/run/lirc/lircd stuff. The TCP sockets (--listen) work at least as
good and are network transparent. And portable (e.g. Java).
Implementing both named pipes and TCP seems suboptimal IMHO. (The
possible advantage is higher performance, which is not relevant here.)

>> Still waiting for an explanation why you changed your mind about d-bus
>> support ;-).
>>
>>
> Basically, I have re-evaluated the multiple sockets/poll() approach. It
> is existing code, portable and actually really fast. Furthermore, the
> kDbus project has been sent back to the design board. I'm not really
> sure that userspace dBus has a latency low enough for our purposes.
...
>
> Adding dBus interfaces to lirc still a good thing. But then as a
> separate connector, similar to e. g., lircd-uinput or a upcoming
> lircd-connect-tcp module  implementing --connect.

Ok.

> BTW, while we are on it: What do you think about adding a
> "send-binary-data" command to irsend?

By "Binary data" you mean "raw IR data" not binary blobs, rite? I did
that several years ago in the "CCF patch". Problem was (then) that it
did not "fit" the Lirc concept, like attaching fins to a automobile does
not create an aircraft... But of course it belongs in a concept
surpassing Lirc. Cf. http://www.harctoolbox.org/Girs.html (which you
already know...)

BTW, your branch still misses the file backend-commands.h.

Greetz,

Bengt

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Alec Leamas

On 11/08/16 19:28, Bengt Martensson wrote:
> BTW, your branch still misses the file backend-commands.h.
>
>

Confusion ?!

$ git ls-files | grep _commands
lircd_commands.cpp
lircd_commands.h
$ git grep backend_commands.h
$


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Bengt Martensson-2
On 08/11/16 20:34, Alec Leamas wrote:
 >
 > On 11/08/16 19:28, Bengt Martensson wrote:
 >> BTW, your branch still misses the file backend-commands.h.
 >>
 >>
 >
 > Confusion ?!
 >
 > $ git ls-files | grep _commands
 > lircd_commands.cpp
 > lircd_commands.h
 > $ git grep backend_commands.h

Actually, I now get:

make[2]: *** No rule to make target 'lircd-backend-tcp.cpp', needed by
'lircd-backend-tcp.o'.  Stop.


$ find . -name lircd-backend-tcp.cpp
$ grep -r  lircd-backend-tcp.cpp .
./daemons/Makefile.in:lircd_backend_tcp_SOURCES = lircd-backend-tcp.cpp
./daemons/Makefile.am:lircd_backend_tcp_SOURCES = lircd-backend-tcp.cpp
./daemons/Makefile:lircd_backend_tcp_SOURCES = lircd-backend-tcp.cpp




------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Alec Leamas
In reply to this post by Bengt Martensson-2



On 11/08/16 19:28, Bengt Martensson wrote:
> BTW, while we are on it: What do you think about adding a
> "send-binary-data" command to irsend?
By "Binary data" you mean "raw IR data" not binary blobs, rite? I did 
that several years ago in the "CCF patch". Problem was (then) that it 
did not "fit" the Lirc concept, like attaching fins to a automobile does 
not create an aircraft... But of course it belongs in a concept 
surpassing Lirc. Cf. http://www.harctoolbox.org/Girs.html (which you 
already know...)
yes, but... one of the reasons for this refactoring is to make it possible to make completely new backends while keeping the API (and while keeping the old code available). With this is mind, wouldn't it might make sense to add a new command which for now just doesn't work ("not implemented")? Just to keep the interfaces sound?

BTW, something like CCF, yes.

--a

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Alec Leamas
In reply to this post by Alec Leamas


On 11/08/16 20:34, Alec Leamas wrote:
>
> On 11/08/16 19:28, Bengt Martensson wrote:
>> BTW, your branch still misses the file backend-commands.h.
>>
>>
>
> Confusion ?!

Yep. Fixed.

--a

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Alec Leamas


On 11/08/16 20:58, Alec Leamas wrote:
>
>> Confusion ?!
>
> Yep. Fixed.
>
Now. Dozens of missing files. Sorry for the mess.

--a


--a

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Bengt Martensson-2
In reply to this post by Alec Leamas
On 08/11/16 12:06, Alec Leamas wrote:
...
>
> I have pushed a WIP branch called ng. It's by no mean functional, just a
> preliminary hack. The state could be described as "works occasionally".

I tried for a while, and could not get it to work. I start lircd, then
lircd-backend-std (it complains about the pid file of lircd, so I have
to delete that), the latter establishes contact with the driver and it
shows up in lircd's log, but irtool just will not give resonable result.
For example, on list-backends it just hangs.

Suggesting: migrate all the named pipes to TCP sockets. (I have
presented the arguments already.) For the backends, there are no
compatibility issues. For client/command, a backwards-compatibility fix
can be implemented.

> The main dispatcher lircd.cpp  is in a reasonable shape. It has a file
> comment describing what it is doing.

Suggestion: change the name; it is highly confusing to recycle the old.

> *lircd-backend-tcp* is a simple backend  implementing the --listen
> option. It's used to pioneer the backend interface.

I do not understand what this program is supposed to do. --listen is
pretty much complementary to what a backend is supposed to do.

> *lircd-backend-std* is  the remaining parts of current lircd
> implementing a backend. The combination of  lircd + a single
> lircd-backend-std should be identical to current lircd.

-o (--output) is not a well chosen name for selecting communicating
socket. That option is normally used (compilers etc) to point at the
file were a product is delivered.

> *irtool* is a new tool aimed to export the complete new control socket
> interface. irtool -h gives a hint. It's the only user tool which is
> aware of the different backends.

> *dummy-backend* is a expect/tcl test tool .

does not work for me:

$ daemons/dummy-backend
spawn socat -,echo=0 UNIX-CONNECT:var/lircd.socket.backend
2016/08/12 13:42:41 socat[11788] E connect(3, AF=1
"var/lircd.socket.backend", 26): No such file or directory
expect: spawn id exp5 not open
     while executing
"expect {
         "SET_DATA_SOCKET*\n" {
             set words [split $expect_out(0,string)]
             set backend_data [lindex $words 1]
            ..."
     ("while" body line 2)
     invoked from within
"while (1) {
     expect {
         "SET_DATA_SOCKET*\n" {
             set words [split $expect_out(0,string)]
             set backend_data [lindex $word..."
     (file "daemons/dummy-backend" line 16)


More later.

Greetz,

Bengt

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Alec Leamas


On 12/08/16 14:06, Bengt Martensson wrote:
> On 08/11/16 12:06, Alec Leamas wrote:
> ...
>> I have pushed a WIP branch called ng. It's by no mean functional, just a
>> preliminary hack. The state could be described as "works occasionally".
> I tried for a while, and could not get it to work.

Let's drop this for now, it's just a hack...
>
> Suggesting: migrate all the named pipes to TCP sockets. (I have
> presented the arguments already.) For the backends, there are no
> compatibility issues. For client/command, a backwards-compatibility fix
> can be implemented.

I cannot really see the argument?. Portability? Given that we might
possibly build lirc on system like BSD and MacOS besides unix named
pipes are no problem. So what is this about, really?

That said, of anything is possible in new interfaces. However, we need
*strong* arguments to change the existing application interface. What
are those strong arguments?
>
>> The main dispatcher lircd.cpp  is in a reasonable shape. It has a file
>> comment describing what it is doing.
> Suggestion: change the name; it is highly confusing to recycle the old.

Agreed.

>> *lircd-backend-tcp* is a simple backend  implementing the --listen
>> option. It's used to pioneer the backend interface.
> I do not understand what this program is supposed to do. --listen is
> pretty much complementary to what a backend is supposed to do.

Not really. In this new architecture, a backend is something which
accepts backend commands and send decoded events to the
yet-to-be-renamed lircd. Whiich is exactly what the listen backend does.

>> *lircd-backend-std* is  the remaining parts of current lircd
>> implementing a backend. The combination of  lircd + a single
>> lircd-backend-std should be identical to current lircd.
> -o (--output) is not a well chosen name for selecting communicating
> socket. That option is normally used (compilers etc) to point at the
> file were a product is delivered.
Agreed. To my defense it's not really 'chosen', it's just a copy-paste
from current lircd.

We need  a name we can use in all places. lircd-new creates three fifos:

lircd is the current application socket
lircd.backend is where backends connect.
llircd.control is where irtool connects

Here 'lircd' is the common path set in the options. Trying --fifos /-f
for now.


As I said, I will not have much time for this for some time.

Cheers!

--alec

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Bengt Martensson-2
On 08/13/16 21:59, Alec Leamas wrote:
>
>
> On 12/08/16 14:06, Bengt Martensson wrote:
>> On 08/11/16 12:06, Alec Leamas wrote:
>> ...
>>> I have pushed a WIP branch called ng. It's by no mean functional, just a
>>> preliminary hack. The state could be described as "works occasionally".
  ....
>> Suggesting: migrate all the named pipes to TCP sockets. (I have
>> presented the arguments already.) For the backends, there are no
>> compatibility issues. For client/command, a backwards-compatibility fix
>> can be implemented.
>
> I cannot really see the argument?. Portability? Given that we might
> possibly build lirc on system like BSD and MacOS besides unix named
> pipes are no problem. So what is this about, really?

Hmm, I did not expect that "harsh" reaction to a friendly suggestion.

The arguments are: network transparency, interoperability with other
systems, and (on third place) portability.

The way I see it, any future home automation/remote control system will
be build around a multitude of different interacting components, on
different hosts, implemented in different languages, from different
manufacturers, possibly some of them free software, some non-free
software. See "Internet of things", cloud based computing etc. A setup
might use several different senors, for example for IR signals, all
connected to a LAN, located in different room, connected to different
bosts. These may be hosted on (among others) PCs, Raspies, Routers,
NASes, Smartphones, IRcomponente like GlobalCache, Arduinos,  esp8266.
etc, etc. Connected over LAN, WLAN, Internet, Bluetooth,... Actually, (I
already have an experimental lird compatible server running on an
Arduino mega.) All of these are useless to a named-pipes-only solution.

You probably say that you like this just as much as I do. But still you
like your solution to be basically non-networked, with network support
later added on(?).

> That said, of anything is possible in new interfaces. However, we need
> *strong* arguments to change the existing application interface.

But you are introducing new interfaces, using the antiquated named
pipes! Where are your "strong argument"?

I do not have a problem with redundant, "legacy", "deprecated"
interfaces (like named pipes), as long as they are exactly that, not the
recommended (or only!) way to do it.


Greetz,

Bengt



  What

> are those strong arguments?
>>
>>> The main dispatcher lircd.cpp  is in a reasonable shape. It has a file
>>> comment describing what it is doing.
>> Suggestion: change the name; it is highly confusing to recycle the old.
>
> Agreed.
>
>>> *lircd-backend-tcp* is a simple backend  implementing the --listen
>>> option. It's used to pioneer the backend interface.
>> I do not understand what this program is supposed to do. --listen is
>> pretty much complementary to what a backend is supposed to do.
>
> Not really. In this new architecture, a backend is something which
> accepts backend commands and send decoded events to the
> yet-to-be-renamed lircd. Whiich is exactly what the listen backend does.
>
>>> *lircd-backend-std* is  the remaining parts of current lircd
>>> implementing a backend. The combination of  lircd + a single
>>> lircd-backend-std should be identical to current lircd.
>> -o (--output) is not a well chosen name for selecting communicating
>> socket. That option is normally used (compilers etc) to point at the
>> file were a product is delivered.
> Agreed. To my defense it's not really 'chosen', it's just a copy-paste
> from current lircd.
>
> We need  a name we can use in all places. lircd-new creates three fifos:
>
> lircd is the current application socket
> lircd.backend is where backends connect.
> llircd.control is where irtool connects
>
> Here 'lircd' is the common path set in the options. Trying --fifos /-f
> for now.
>
>
> As I said, I will not have much time for this for some time.

My

>
> Cheers!
>
> --alec
>


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New lircd design (Was: Raw codes and toggle bits)

Alec Leamas


On 14/08/16 12:36, Bengt Martensson wrote:

> On 08/13/16 21:59, Alec Leamas wrote:
>>
>> On 12/08/16 14:06, Bengt Martensson wrote:
>>> On 08/11/16 12:06, Alec Leamas wrote:
>>> ...
>>>> I have pushed a WIP branch called ng. It's by no mean functional, just a
>>>> preliminary hack. The state could be described as "works occasionally".
>    ....
>>> Suggesting: migrate all the named pipes to TCP sockets. (I have
>>> presented the arguments already.) For the backends, there are no
>>> compatibility issues. For client/command, a backwards-compatibility fix
>>> can be implemented.
>> I cannot really see the argument?. Portability? Given that we might
>> possibly build lirc on system like BSD and MacOS besides unix named
>> pipes are no problem. So what is this about, really?
> Hmm, I did not expect that "harsh" reaction to a friendly suggestion.
As said earlier in a PM, I had no intent to send a "harsh" answer. Sorry
if you perceived it as such. In the end, we all could have some problems
with the nuances in English, I guess.
>
> The arguments are: network transparency, interoperability with other
> systems, and (on third place) portability.

As for network transparency, it's certainly an argument. However, it
comes to a cost: an open network socket is a security issue, and makes
setup more complicated since the time when we could register a service
in /etc/services is long time passed. Distribution-wise e. g., Fedora
does not allow automatic enabling of network services, so user need to
meddle with firewalls and systemd before things is up & running. On top
of that we have the pure cost of changing the now well-established
socket interface.

This is not an argument against that the frontend should be
network-aware. After some thinking I think I agree on that the --listen
capabilities perhaps should be a an integral part of the frontend, on
equal basis with the name pipe interface as today. But I really don't
see the point in deprecating the named pipes client interface .

The same goes for the connection backend-frontend, I think. But, with a
network-aware  frontend we should keep the design open for also for
backends connecting over the network. Your vision is sound, and I guess
we will have a usecase sooner or later. This is partly also about being
able to interoperate with other systems.

However,  I don't understand the portability issue. After all, a named
pipe is nothing but a POSIX file which can be read and written using
well-established APIs, right? I cannot see that that this is less
portable than a network connection. Am I missing something here? Or do
you refer to the problems *creating* a named pipe in Java?

Cheers!

--alec

------------------------------------------------------------------------------
Loading...