lirc on macos

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

lirc on macos

Alec Leamas
Hi out there!


It has turned out that the state of lirc on macos is, well, "not ideal".
We need to fix this.

I have pushed a new feature branch called 'macos'. It can be cloned using

git clone --branch macos  git://git.code.sf.net/p/lirc/git lirc-macos

The branch contains the already tested compilation fixes (cleaned up)
and also a more sane handling of the failing poll(): I have shamelessly
stolen the curl wrapper code which is able to use select() instead of
poll() if the latter does not work.

This patch does *not* pull in any old code and is perfectly acceptable
upstream. However, it now needs some testing on macos, a platform I
don't have at hand.

So: branch tests and feedback from mac users would be appreciated.

This also mean that the previous patches are more or less obsolete, in
particular the attempt to "fix" the failing  poll() by using the old
0.9.2 code. I hindsight, that was a patch I certainly shouldn't have
made. Sorry.


Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Craig Treleaven
> On Oct 18, 2016, at 9:30 AM, Alec Leamas <[hidden email]> wrote:
>
> Hi out there!
>
>
> It has turned out that the state of lirc on macos is, well, "not ideal".
> We need to fix this.
>
> I have pushed a new feature branch called 'macos'. It can be cloned using
>
> git clone --branch macos  git://git.code.sf.net/p/lirc/git lirc-macos
>
> The branch contains the already tested compilation fixes (cleaned up)
> and also a more sane handling of the failing poll(): I have shamelessly
> stolen the curl wrapper code which is able to use select() instead of
> poll() if the latter does not work.
>
> This patch does *not* pull in any old code and is perfectly acceptable
> upstream. However, it now needs some testing on macos, a platform I
> don't have at hand.
>
> So: branch tests and feedback from mac users would be appreciated.
>
> This also mean that the previous patches are more or less obsolete, in
> particular the attempt to "fix" the failing  poll() by using the old
> 0.9.2 code. I hindsight, that was a patch I certainly shouldn't have
> made. Sorry.

OK, I successfully built the new branch but it seems to be trying to use poll() still.

Configure includes:

checking portaudio.h usability... yes
checking portaudio.h presence... yes
checking for portaudio.h... yes
checking for Pa_Initialize in -lportaudio... yes
checking alsa/asoundlib.h usability... no
checking alsa/asoundlib.h presence... no
checking for alsa/asoundlib.h... no
poll() works
configure: poll() seems to work...
checking linux/input.h usability... no
checking linux/input.h presence... no
checking for linux/input.h... no
configure: WARNING: Cannot find kernel headers
checking linux/lirc.h usability... no
checking linux/lirc.h presence... no
checking for linux/lirc.h… no

As before, CPU usage goes to 100% after lircd receives UDP data.

Craig
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Alec Leamas


On 18/10/16 22:31, Craig Treleaven wrote:

>
> OK, I successfully built the new branch but it seems to be trying to use poll() still.
>
> Configure includes:
>
> checking portaudio.h usability... yes
> checking portaudio.h presence... yes
> checking for portaudio.h... yes
> checking for Pa_Initialize in -lportaudio... yes
> checking alsa/asoundlib.h usability... no
> checking alsa/asoundlib.h presence... no
> checking for alsa/asoundlib.h... no
> poll() works
> configure: poll() seems to work...
> checking linux/input.h usability... no
> checking linux/input.h presence... no
> checking for linux/input.h... no
> configure: WARNING: Cannot find kernel headers
> checking linux/lirc.h usability... no
> checking linux/lirc.h presence... no
> checking for linux/lirc.h… no

Hm... this is, as they say "odd". The configure script contains a test
that supposedly should be able to detect the poll bug, but perhaps it fails?

Can you try to patch config.h, after ./configure... and before 'make',
undefining the HAVE_POLL_FINE conditional and report back?

Another issue: If you compile and run following code, what is the return
code?

   #include <poll.h>
   #include <stdio.h>
   #include <sys/time.h>
   int main(int argc, char** argv)
   {
     struct timeval before, after;
     int rc;
     size_t us;

     gettimeofday(&before, NULL);
     rc = poll(NULL, 0, 500);
     gettimeofday(&after, NULL);

     us = (after.tv_sec - before.tv_sec) * 1000000 +
       (after.tv_usec - before.tv_usec);

     return us >= 400000 ? 0 : 1;
   }


Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Craig Treleaven
> On Oct 18, 2016, at 4:46 PM, Alec Leamas <[hidden email]> wrote:
> On 18/10/16 22:31, Craig Treleaven wrote:
>> OK, I successfully built the new branch but it seems to be trying to use poll() still.
>>
>> Configure includes:
>>
>> checking portaudio.h usability... yes
>> checking portaudio.h presence... yes
>> checking for portaudio.h... yes
>> checking for Pa_Initialize in -lportaudio... yes
>> checking alsa/asoundlib.h usability... no
>> checking alsa/asoundlib.h presence... no
>> checking for alsa/asoundlib.h... no
>> poll() works
>> configure: poll() seems to work...
>> checking linux/input.h usability... no
>> checking linux/input.h presence... no
>> checking for linux/input.h... no
>> configure: WARNING: Cannot find kernel headers
>> checking linux/lirc.h usability... no
>> checking linux/lirc.h presence... no
>> checking for linux/lirc.h… no
>
> Hm... this is, as they say "odd". The configure script contains a test that supposedly should be able to detect the poll bug, but perhaps it fails?
>
> Can you try to patch config.h, after ./configure... and before 'make', undefining the HAVE_POLL_FINE conditional and report back?
>
I’ll try this and report back.

> Another issue: If you compile and run following code, what is the return code?
>
>  #include <poll.h>
>  #include <stdio.h>
>  #include <sys/time.h>
>  int main(int argc, char** argv)
>  {
>    struct timeval before, after;
>    int rc;
>    size_t us;
>
>    gettimeofday(&before, NULL);
>    rc = poll(NULL, 0, 500);
>    gettimeofday(&after, NULL);
>
>    us = (after.tv_sec - before.tv_sec) * 1000000 +
>      (after.tv_usec - before.tv_usec);
>
>    return us >= 400000 ? 0 : 1;
>  }
Ah, the above test is from https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/

He specifically says that poll() was again changed in macOS 10.12 (“Sierra”) and this test finds the new breakage.  I am not running 10.12, I’m 2 versions back:

CT-MBP11:lirc-devel craigtreleaven$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.10.5
BuildVersion: 14F1912

When I run the test on my system, I get the following:

CT-MBP11:lirc-devel craigtreleaven$ clang poll_test.c
CT-MBP11:lirc-devel craigtreleaven$ ./a.out ; echo $?
0
CT-MBP11:lirc-devel craigtreleaven$ time ./a.out

real 0m0.506s
user 0m0.002s
sys 0m0.003s

He says that poll() works fine (for them?) in versions 10.9 through 10.11.  I don’t know why it jumps to 100% CPU after data starts arriving for us.

I think the expedient solution would be to configure to always use select() on Darwin.

Craig
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Alec Leamas


On 19/10/16 02:42, Craig Treleaven wrote:

> Ah, the above test is from https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/

Indeed ;)

> When I run the test on my system, I get the following:
>
> CT-MBP11:lirc-devel craigtreleaven$ clang poll_test.c
> CT-MBP11:lirc-devel craigtreleaven$ ./a.out ; echo $?
> 0

> I think the expedient solution would be to configure to always use select() on Darwin.

If nothing else works, you can always patch config.h the way described
in previous message (just remove the HAVE_POLL_FINE line). That said, to
have a proper test which actually identifies the bug is of course better
(what if apple actually fixes this is in an upcoming version?).

The test below runs successfully on Linux. What is the return code on
your macos?

Cheers!

--alec



#include <errno.h>
#include <fcntl.h>
#include <poll.h>
#include <stdio.h>
#include <sys/time.h>

int main(void)
{
   int fd = open("/dev/tty", O_RDONLY);
   if (fd == -1) return 2;
   struct pollfd pfd = {fd, 1, 0};

   struct timeval before, after;
   gettimeofday(&before, NULL);
   int rc = poll(&pfd, 1, 500);
   if (rc < 0) return errno;
   if (rc > 0) return rc;
   gettimeofday(&after, NULL);

   suseconds_t us = (after.tv_sec - before.tv_sec) * 1000000 +
     (after.tv_usec - before.tv_usec);
   return us >= 400000 ? 0 : 1;
}

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Craig Treleaven
> On Oct 19, 2016, at 5:57 AM, Alec Leamas <[hidden email]> wrote:
>
> On 19/10/16 02:42, Craig Treleaven wrote:
>
>> Ah, the above test is from https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
>
> Indeed ;)
>
>> When I run the test on my system, I get the following:
>>
>> CT-MBP11:lirc-devel craigtreleaven$ clang poll_test.c
>> CT-MBP11:lirc-devel craigtreleaven$ ./a.out ; echo $?
>> 0
>
>> I think the expedient solution would be to configure to always use select() on Darwin.
>
> If nothing else works, you can always patch config.h the way described in previous message (just remove the HAVE_POLL_FINE line). That said, to have a proper test which actually identifies the bug is of course better (what if apple actually fixes this is in an upcoming version?).
>
Sorry Alec, but something else seems to be going on.  I commented out the HAVE_POLL_FINE line.  Using irw, I only see a small fraction of the keypresses expected.  In the following session, I pressed pretty much each key on the remote (about 27):

CT-MBP11:lirc-devel craigtreleaven$ irw
000040040d00c1cc 00 CANCEL veq2249
000040040d00d9d4 00 TITLE veq2249
000040040d00e1ec 00 LEFT veq2249
000040040d00414c 00 SELECT veq2249
000040040d00414c 01 SELECT veq2249
000040040d00929f 00 SKIP-BACK veq2249
000040040d004845 00 3 veq2249
^C

For example, I pressed the four arrow keys and only LEFT was reported; I pressed the 10 number keys and only “3” was reported.  

I confirmed that lircd is calling select().  In Activity Monitor, CPU usage is 0; lircd is waiting on the __select function.

Hmm, just tried again, and different keys worked.  This time, I pressed each arrow key 4 times and each number pad key twice:

CT-MBP11:lirc-devel craigtreleaven$ irw
000040040d00a1ac 00 UP veq2249
000040040d00a1ac 00 UP veq2249
000040040d00616c 00 DOWN veq2249
000040040d00111c 00 RIGHT veq2249
000040040d00111c 00 RIGHT veq2249
000040040d008885 00 2 veq2249
000040040d004845 00 3 veq2249
000040040d002825 00 5 veq2249
000040040d002825 01 5 veq2249
000040040d00e8e5 00 8 veq2249
000040040d00e8e5 01 8 veq2249
000040040d00e8e5 00 8 veq2249
000040040d001815 00 9 veq2249
^C

BTW, my HDHomerun box is connected to a network switch that is also in line of sight.  I can see the light flashing on the network switch indicating data passing through each time I press a button on the remote.  So I don’t think there is a problem with the hardware.

Do you have a way to test UDP on Linux?

> The test below runs successfully on Linux. What is the return code on your macos?
>
> Cheers!
>
> --alec
>
>
>
> #include <errno.h>
> #include <fcntl.h>
> #include <poll.h>
> #include <stdio.h>
> #include <sys/time.h>
>
> int main(void)
> {
>  int fd = open("/dev/tty", O_RDONLY);
>  if (fd == -1) return 2;
>  struct pollfd pfd = {fd, 1, 0};
>
>  struct timeval before, after;
>  gettimeofday(&before, NULL);
>  int rc = poll(&pfd, 1, 500);
>  if (rc < 0) return errno;
>  if (rc > 0) return rc;
>  gettimeofday(&after, NULL);
>
>  suseconds_t us = (after.tv_sec - before.tv_sec) * 1000000 +
>    (after.tv_usec - before.tv_usec);
>  return us >= 400000 ? 0 : 1;
> }

Return code from the above is always 1:

CT-MBP11:lirc-devel craigtreleaven$ ./a.out ; echo $?
1

Regarding a proper test, as I understand it, there is a performance difference between poll() and select().  I think performance is probably more important to curl.  I think lirc is generally dealing with much lower data rates and it likely doesn’t matter?

Craig
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Alec Leamas


On 19/10/16 14:43, Craig Treleaven wrote:

> Return code from the above is always 1:
>
> CT-MBP11:lirc-devel craigtreleaven$ ./a.out ; echo $?
> 1
>

Basically, this means we have a working test, since it fails on macos. A
small step, but still... I will update the macos branch.

--a

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Alec Leamas
In reply to this post by Craig Treleaven


On 19/10/16 14:43, Craig Treleaven wrote:

>> On Oct 19, 2016, at 5:57 AM, Alec Leamas <[hidden email]> wrote:
>>
>> On 19/10/16 02:42, Craig Treleaven wrote:
>>
>>> Ah, the above test is from https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
>>
>> Indeed ;)
>>
>>> When I run the test on my system, I get the following:
>>>
>>> CT-MBP11:lirc-devel craigtreleaven$ clang poll_test.c
>>> CT-MBP11:lirc-devel craigtreleaven$ ./a.out ; echo $?
>>> 0
>>
>>> I think the expedient solution would be to configure to always use select() on Darwin.
>>
>> If nothing else works, you can always patch config.h the way described in previous message (just remove the HAVE_POLL_FINE line). That said, to have a proper test which actually identifies the bug is of course better (what if apple actually fixes this is in an upcoming version?).
>>
> Sorry Alec, but something else seems to be going on.  I commented out the HAVE_POLL_FINE line.  Using irw, I only see a small fraction of the keypresses expected.  In the following session, I pressed pretty much each key on the remote (about 27):
>
> CT-MBP11:lirc-devel craigtreleaven$ irw
> 000040040d00c1cc 00 CANCEL veq2249
> 000040040d00d9d4 00 TITLE veq2249
> 000040040d00e1ec 00 LEFT veq2249
> 000040040d00414c 00 SELECT veq2249
> 000040040d00414c 01 SELECT veq2249
> 000040040d00929f 00 SKIP-BACK veq2249
> 000040040d004845 00 3 veq2249
> ^C
>
> For example, I pressed the four arrow keys and only LEFT was reported; I pressed the 10 number keys and only “3” was reported.


OK, progress, new errors.

First, have you set the loglevel to at least log_trace and checked that
the lircd log doesn't contain something bad, especially from the udp driver?

Second, what if you use irrecord to record just a few buttons? Can you
make this work? To me, this looks like the either the signals or the
config file is bad. (Batteries? Too close? )

> Do you have a way to test UDP on Linux?

No, Overall, lirc test tools is a sad chapter.


Cheers!

--alec



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Craig Treleaven
> On Oct 19, 2016, at 9:27 AM, Alec Leamas <[hidden email]> wrote:
>
> On 19/10/16 14:43, Craig Treleaven wrote:
>>> On Oct 19, 2016, at 5:57 AM, Alec Leamas <[hidden email]> wrote:
>>>
>>> On 19/10/16 02:42, Craig Treleaven wrote:
>>>
>>>> Ah, the above test is from https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
>>>
>>> Indeed ;)
>>>
>>>> When I run the test on my system, I get the following:
>>>>
>>>> CT-MBP11:lirc-devel craigtreleaven$ clang poll_test.c
>>>> CT-MBP11:lirc-devel craigtreleaven$ ./a.out ; echo $?
>>>> 0
>>>
>>>> I think the expedient solution would be to configure to always use select() on Darwin.
>>>
>>> If nothing else works, you can always patch config.h the way described in previous message (just remove the HAVE_POLL_FINE line). That said, to have a proper test which actually identifies the bug is of course better (what if apple actually fixes this is in an upcoming version?).
>>>
>> Sorry Alec, but something else seems to be going on.  I commented out the HAVE_POLL_FINE line.  Using irw, I only see a small fraction of the keypresses expected.  In the following session, I pressed pretty much each key on the remote (about 27):
>>
>> CT-MBP11:lirc-devel craigtreleaven$ irw
>> 000040040d00c1cc 00 CANCEL veq2249
>> 000040040d00d9d4 00 TITLE veq2249
>> 000040040d00e1ec 00 LEFT veq2249
>> 000040040d00414c 00 SELECT veq2249
>> 000040040d00414c 01 SELECT veq2249
>> 000040040d00929f 00 SKIP-BACK veq2249
>> 000040040d004845 00 3 veq2249
>> ^C
>>
>> For example, I pressed the four arrow keys and only LEFT was reported; I pressed the 10 number keys and only “3” was reported.
>
>
> OK, progress, new errors.
>
> First, have you set the loglevel to at least log_trace and checked that the lircd log doesn't contain something bad, especially from the udp driver?
>
> Second, what if you use irrecord to record just a few buttons? Can you make this work? To me, this looks like the either the signals or the config file is bad. (Batteries? Too close? )
>
>> Do you have a way to test UDP on Linux?
>
> No, Overall, lirc test tools is a sad chapter.

Couple of things:

1) I have never been able to change the loglevel via lirc_options.conf.  Only with command line arguments?

With loglevel=trace, pressed each of the arrow keys twice.  irw showed:

CT-MBP11:lirc-devel craigtreleaven$ irw
000040040d00a1ac 00 UP veq2249
000040040d00e1ec 00 LEFT veq2249
^C


Log contains:

Oct 19 10:01:45.007032 CT-MBP11.local lircd: Info: lircd:  Opening log, level: Info
Oct 19 10:01:45.025234 CT-MBP11.local lircd: Info: Initial device: 5000
Oct 19 10:01:45.025271 CT-MBP11.local lircd: Info: Initial device: 5000
Oct 19 10:01:45.025302 CT-MBP11.local lircd: Trace: lircd:  Opening log, level: Trace
Oct 19 10:01:45.029018 CT-MBP11.local lircd: Notice: Running as user _lirc
Oct 19 10:01:45.029039 CT-MBP11.local lircd: Debug: Groups: [501]: 501 12 61 100
Oct 19 10:01:45.029047 CT-MBP11.local lircd: Trace: started server socket
Oct 19 10:01:45.029318 CT-MBP11.local lircd: Trace: parsing remote
Oct 19 10:01:45.029358 CT-MBP11.local lircd: Info: Using remote: veq2249.
Oct 19 10:01:45.029875 CT-MBP11.local lircd: Trace: lengths: 129040 134350 74694 74694
Oct 19 10:01:45.030270 CT-MBP11.local lircd: Trace: lengths: 129040 134350 74694 74694
Oct 19 10:01:45.030332 CT-MBP11.local lircd: Trace: config file read
Oct 19 10:01:45.030363 CT-MBP11.local lircd: Notice: lircd(udp) ready, using /opt/local/var/run/lirc/lircd
Oct 19 10:02:18.944871 CT-MBP11.local lircd: Trace: registering local client
Oct 19 10:02:18.944931 CT-MBP11.local lircd: Notice: accepted new client on /opt/local/var/run/lirc/lircd
Oct 19 10:02:29.553992 CT-MBP11.local lircd: Trace: writing to client 0: 000040040d00a1ac 00 UP veq2249

Oct 19 10:02:34.483342 CT-MBP11.local lircd: Trace: writing to client 0: 000040040d00e1ec 00 LEFT veq2249

Oct 19 10:02:50.313406 CT-MBP11.local lircd: Info: removed client


The batteries are good.  This is a rechargeable Harmony 680 that I use for my home theatre.  I programmed it several years ago to emulate a Panasonic VEQ2249.  I’ve used this conf file with previous versions of lirc.  At one point, I had loglevel=trace2 (I think) and I believe it parsed the file with no errors.

Re irrecord, I’ve never had any success using it.  If you can give me cookbook-style instructions, I can try what you want.  Earlier, I ran mode2 and got hundreds of lines of output for a dozen or so button presses.  

As aways, thanks for all your work on this.

Craig
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Alec Leamas


On 19/10/16 16:14, Craig Treleaven wrote:
1ec 00 LEFT veq2249
>
> Oct 19 10:02:50.313406 CT-MBP11.local lircd: Info: removed client

Well, nothing bad in the logs. So, the udp driver seems happy.

> Earlier, I ran mode2 and got hundreds of lines of output for a dozen or so button presses.

And now, what happens when running mode2?

> Re irrecord, I’ve never had any success using it.  If you can give me cookbook-style instructions, I can try what you want.  Earlier, I ran mode2 and got hundreds of lines of output for a dozen or so button presses.

Actually, the command line output from that tool is really
cookbook-style. It is pretty clear what it expects, I would say.
However, the first step is running mode2.

> As always, thanks for all your work on this.

You are welcome, and the the same to you! Making this work again also on
macos would actually make me sleep much better :)


Cheers!

--a

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Craig Treleaven
> On Oct 19, 2016, at 10:26 AM, Alec Leamas <[hidden email]> wrote:
>
> On 19/10/16 16:14, Craig Treleaven wrote:
> 1ec 00 LEFT veq2249
>>
>> Oct 19 10:02:50.313406 CT-MBP11.local lircd: Info: removed client
>
> Well, nothing bad in the logs. So, the udp driver seems happy.
>
>> Earlier, I ran mode2 and got hundreds of lines of output for a dozen or so button presses.
>
> And now, what happens when running mode2?
>

Pressed the Up arrow key only:

http://paste.fedoraproject.org/455742/76893233/


>> Re irrecord, I’ve never had any success using it.  If you can give me cookbook-style instructions, I can try what you want.  Earlier, I ran mode2 and got hundreds of lines of output for a dozen or so button presses.
>
> Actually, the command line output from that tool is really cookbook-style. It is pretty clear what it expects, I would say. However, the first step is running mode2.

irrecord —update —driver=udp —device=5000 vte2249.conf

The above sort of works but the keys I try to update get deleted, not changed.  There are quite a few minor changes to the file but the only substantive-looking ones are:

  toggle_bit      0

becomes...

  toggle_bit_mask 0x0
  frequency    38000

Is that important?

Craig
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Alec Leamas


On 19/10/16 18:45, Craig Treleaven wrote:
>> On Oct 19, 2016, at 10:26 AM, Alec Leamas <[hidden email]> wrote:

>> And now, what happens when running mode2?
>>
>
> Pressed the Up arrow key only:
>
> http://paste.fedoraproject.org/455742/76893233/

At a glance, this looks just fine. A great step forward!


>>
>> Actually, the command line output from that tool is really cookbook-style. It is pretty clear what it expects, I would say. However, the first step is running mode2.
>
> irrecord —update —driver=udp —device=5000 vte2249.conf
>
> The above sort of works but the keys I try to update get deleted, not changed.  There are quite a few minor changes to the file but the only substantive-looking ones are:
>

Using the --update option means that irrecord will not identify your
remote "from scratch". A perhaps better test might be to skip the
--update and let irrecord create a  new file. This means possible new
values for a lot of important parameters. It should be enough to record
just a few keys e. g., four or five.

The changes made to that your file by --update does not look significant
to me (knock, knock...)


Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Craig Treleaven
> On Oct 19, 2016, at 2:32 PM, Alec Leamas <[hidden email]> wrote:
>
> On 19/10/16 18:45, Craig Treleaven wrote:
>>> On Oct 19, 2016, at 10:26 AM, Alec Leamas <[hidden email]> wrote:
>
> ...
>>>
>>> Actually, the command line output from that tool is really cookbook-style. It is pretty clear what it expects, I would say. However, the first step is running mode2.
>>
>> irrecord —update —driver=udp —device=5000 vte2249.conf
>>
>> The above sort of works but the keys I try to update get deleted, not changed.  There are quite a few minor changes to the file but the only substantive-looking ones are:
>>
>
> Using the --update option means that irrecord will not identify your remote "from scratch". A perhaps better test might be to skip the --update and let irrecord create a  new file. This means possible new values for a lot of important parameters. It should be enough to record just a few keys e. g., four or five.
>
> The changes made to that your file by --update does not look significant to me (knock, knock…)

Yeah, I haven’t been able to create a new file; tried a few times.  See example transcript at:

http://pastebin.com/9ddSMJQd

Note that it is a bit awkward for me as the IR receiver isn’t in the same room with my computer.  I can move my laptop if need be.

Craig
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: lirc on macos

Craig Treleaven
> On Oct 19, 2016, at 3:25 PM, Craig Treleaven <[hidden email]> wrote:
>
>> On Oct 19, 2016, at 2:32 PM, Alec Leamas <[hidden email]> wrote:
>>
>> On 19/10/16 18:45, Craig Treleaven wrote:
>>>> On Oct 19, 2016, at 10:26 AM, Alec Leamas <[hidden email]> wrote:
>>
>> ...
>>>>
>>>> Actually, the command line output from that tool is really cookbook-style. It is pretty clear what it expects, I would say. However, the first step is running mode2.
>>>
>>> irrecord —update —driver=udp —device=5000 vte2249.conf
>>>
>>> The above sort of works but the keys I try to update get deleted, not changed.  There are quite a few minor changes to the file but the only substantive-looking ones are:
>>>
>>
>> Using the --update option means that irrecord will not identify your remote "from scratch". A perhaps better test might be to skip the --update and let irrecord create a  new file. This means possible new values for a lot of important parameters. It should be enough to record just a few keys e. g., four or five.
>>
>> The changes made to that your file by --update does not look significant to me (knock, knock…)
>
> Yeah, I haven’t been able to create a new file; tried a few times.  See example transcript at:
>
> http://pastebin.com/9ddSMJQd
>
> Note that it is a bit awkward for me as the IR receiver isn’t in the same room with my computer.  I can move my laptop if need be.

To close the loop on this…I created the reception problems myself!  <Insert red face, here.>   Some time ago, I was running out of space and mounted my HDHomerun box on the wall—not horizontal but on its side. The remote seems to be working perfectly if I hold it ON ITS SIDE, as well.   I had no idea that orientation mattered.

I’ve apologized to Alec for the wild goose chase.  At this point, I think lircd is working fine on OS X.

When we get a new Lirc release incorporating Alec’s fixes, I’ll update MacPorts to make the new version available that way.  (The older 0.9.0 release has been on MacPorts for some time [1].)

[1] https://www.macports.org/ports.php?by=name&substr=lirc

I don’t know much about HomeBrew but I imagine it would be fairly straightforward to build with that system too.  Someone just has to create a formula.

Craig
(Alec, I owe you a tasty beverage of your choosing!)


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot