Re: [BUG] ir-ctl: error sending file with multiple scancodes

2017-11-30 Thread Sean Young
Hi Matthias,

On Thu, Nov 30, 2017 at 04:34:33PM +0100, Matthias Reichl wrote:
> Hi Sean,
> 
> On Wed, Nov 29, 2017 at 08:05:21PM +, Sean Young wrote:
> > On Wed, Nov 29, 2017 at 03:44:00PM +0100, Matthias Reichl wrote:
> > > The goal I'm trying to achieve is to send a repeated signal with ir-ctl
> > > (a user reported his sony receiver needs this to actually power up).
> > 
> > That's interesting.
> 
> I'm not sure how common that is. I've got a Panasonic TV here
> that needs a 0.5-1sec button press to power up from standby,
> but it could well be that this is a rather nieche issue.
> 
> I had a look at what it would take to add proper repeat handling
> to ir-ctl (similar to the --count  option in lirc's irsend)
> but that looks like a larger endeavour: implement automatic
> variable length gaps to get fixed repeat times, handle toggle
> bits in some protocols, send special repeat codes eg in NEC etc.

Yes, I've thought about that too. I'm not sure what the user inferface
should look like (and how useful it is).

> As I'm not sure if all of this is even needed I think it's best
> to leave it for maybe some time later. For now the current
> functionality in ir-ctl looks sufficient.

If you have any suggestions. :-)

> > > Using the -S option multiple times comes rather close, but the 125ms
> > > delay between signals is a bit long for the sony protocol - would be
> > > nice if that would be adjustable :)
> > 
> > Yes, that would be a useful feature.
> > 
> > I've got some patches for this, I'll send them as a reply to this. Please
> > let me know what you think.
> 
> [PATCH 1/2] ir-ctl: fix multiple scancodes in one file 
> 01-multiple-scancodes.patch
> [PATCH 2/2] ir-ctl: specify the gap between scancodes or files
> 
> Tested-by: Matthias Reichl 
> 
> Thanks, the patches look and tested fine!
> 
> I've tested multiple scancodes in a file with and without explicit
> space in between and the gap option with multiple -S scancodes on
> the command line. I also tested rc5 protocol in addition to sony12.
> 
> So I'd like to say a big thank you for fixing the issue so quickly!

Thanks for making ir-ctl a better tool :)


Sean


Re: [BUG] ir-ctl: error sending file with multiple scancodes

2017-11-30 Thread Matthias Reichl
Hi Sean,

On Wed, Nov 29, 2017 at 08:05:21PM +, Sean Young wrote:
> On Wed, Nov 29, 2017 at 03:44:00PM +0100, Matthias Reichl wrote:
> > The goal I'm trying to achieve is to send a repeated signal with ir-ctl
> > (a user reported his sony receiver needs this to actually power up).
> 
> That's interesting.

I'm not sure how common that is. I've got a Panasonic TV here
that needs a 0.5-1sec button press to power up from standby,
but it could well be that this is a rather nieche issue.

I had a look at what it would take to add proper repeat handling
to ir-ctl (similar to the --count  option in lirc's irsend)
but that looks like a larger endeavour: implement automatic
variable length gaps to get fixed repeat times, handle toggle
bits in some protocols, send special repeat codes eg in NEC etc.

As I'm not sure if all of this is even needed I think it's best
to leave it for maybe some time later. For now the current
functionality in ir-ctl looks sufficient.

> > Using the -S option multiple times comes rather close, but the 125ms
> > delay between signals is a bit long for the sony protocol - would be
> > nice if that would be adjustable :)
> 
> Yes, that would be a useful feature.
> 
> I've got some patches for this, I'll send them as a reply to this. Please
> let me know what you think.

[PATCH 1/2] ir-ctl: fix multiple scancodes in one file 
01-multiple-scancodes.patch
[PATCH 2/2] ir-ctl: specify the gap between scancodes or files

Tested-by: Matthias Reichl 

Thanks, the patches look and tested fine!

I've tested multiple scancodes in a file with and without explicit
space in between and the gap option with multiple -S scancodes on
the command line. I also tested rc5 protocol in addition to sony12.

So I'd like to say a big thank you for fixing the issue so quickly!

so long,

Hias


Re: [BUG] ir-ctl: error sending file with multiple scancodes

2017-11-29 Thread Sean Young
Hi Matthias,

On Wed, Nov 29, 2017 at 03:44:00PM +0100, Matthias Reichl wrote:
> Hi Sean!
> 
> According to the ir-ctl manpage it should be possible to send a file
> containing multiple scancodes, but when trying to do this I get
> a warning and an error message.
> 
> I initially noticed that on version 1.12.3 but 1.12.5 and master
> (rev 85f8e5a99) give the same error.
> 
> Sending a file with a single scancode or using the -S option
> to specify the scancode on the command line both work fine.
> 
> I've tested with the following file:
> 
> scancode sony12:0x100015
> space 25000
> scancode sony12:0x100015
> 
> Trying to send it gives this:
> $ ./utils/ir-ctl/ir-ctl -s ../sony-test.irctl
> warning: ../sony-test.irctl:2: trailing space ignored
> /dev/lirc0: failed to send: Invalid argument
> 
> Checking with the -v option gives some interesting output - it
> looks like the the second half of the buffer hadn't been filled in:
> 
> $ ./utils/ir-ctl/ir-ctl -v -s ../sony-test.irctl
> warning: ../sony-test.irctl:2: trailing space ignored
> Sending:
> pulse 2400
> space 600
> pulse 1200
> space 600
> pulse 600
> space 600
> pulse 1200
> space 600
> pulse 600
> space 600
> pulse 1200
> space 600
> pulse 600
> space 600
> pulse 600
> space 600
> pulse 600
> space 600
> pulse 600
> space 600
> pulse 600
> space 600
> pulse 600
> space 600
> pulse 1200
> space 600
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> space 0
> pulse 0
> /dev/lirc0: failed to send: Invalid argument

Oh dear, that looks very broken! Looks like I did not test multiple
scancodes in one file.

> The goal I'm trying to achieve is to send a repeated signal with ir-ctl
> (a user reported his sony receiver needs this to actually power up).

That's interesting.

> Using the -S option multiple times comes rather close, but the 125ms
> delay between signals is a bit long for the sony protocol - would be
> nice if that would be adjustable :)

Yes, that would be a useful feature.

I've got some patches for this, I'll send them as a reply to this. Please
let me know what you think.

Thanks,

Sean


[BUG] ir-ctl: error sending file with multiple scancodes

2017-11-29 Thread Matthias Reichl
Hi Sean!

According to the ir-ctl manpage it should be possible to send a file
containing multiple scancodes, but when trying to do this I get
a warning and an error message.

I initially noticed that on version 1.12.3 but 1.12.5 and master
(rev 85f8e5a99) give the same error.

Sending a file with a single scancode or using the -S option
to specify the scancode on the command line both work fine.

I've tested with the following file:

scancode sony12:0x100015
space 25000
scancode sony12:0x100015

Trying to send it gives this:
$ ./utils/ir-ctl/ir-ctl -s ../sony-test.irctl
warning: ../sony-test.irctl:2: trailing space ignored
/dev/lirc0: failed to send: Invalid argument

Checking with the -v option gives some interesting output - it
looks like the the second half of the buffer hadn't been filled in:

$ ./utils/ir-ctl/ir-ctl -v -s ../sony-test.irctl
warning: ../sony-test.irctl:2: trailing space ignored
Sending:
pulse 2400
space 600
pulse 1200
space 600
pulse 600
space 600
pulse 1200
space 600
pulse 600
space 600
pulse 1200
space 600
pulse 600
space 600
pulse 600
space 600
pulse 600
space 600
pulse 600
space 600
pulse 600
space 600
pulse 600
space 600
pulse 1200
space 600
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
/dev/lirc0: failed to send: Invalid argument

The goal I'm trying to achieve is to send a repeated signal with ir-ctl
(a user reported his sony receiver needs this to actually power up).

Using the -S option multiple times comes rather close, but the 125ms
delay between signals is a bit long for the sony protocol - would be
nice if that would be adjustable :)

so long,

Hias