[pvrusb2] Trouble with lirc

[Mike Isely]

On Tue, 9 May 2006, Frans Meulenbroeks wrote:

> Jeff, Mike, all
>
> The cvs version will probably fix the compile problem
> (but I think my patch fixes this too).
>
> The odd thing is that the remote is a standard RC5
> command. Lirc comes with a conf file for a std RC5
> remote and this one does not work.
> Meanwhile I found out that the conf file in the
> pvrusb2 zip is indeed different and contains the codes
> I see with mode2, sot hat one will probably work.
> What still puzzles me, is why I do not get the RC5
> codes I was expecting.
>

The conf file in the pvrusb2 snapshot by the way is something I put 
together about 1.5 years ago when I was experimenting with a PVR-250.  I 
have no idea about what "RC5" standard is supposed to mean.  But what I 
did do was to find a few example conf files floating around the net that 
sort of worked for our remote.  I analyzed those files, tried to "record" 
some codes, figured out the common pieces, and then I created a cleaned up 
conf file which is what is in the driver snapshot you have now.  I use 
that same conf file today with perfect reliability on a mythtv setup I 
have (though in that case it's a PVR-250 not a PVR USB2 however the remote 
included with the package is identical).

One nice thing about the lirc approach is that the configuration that is 
specific to the remote you use is completely independent from the 
configuration that is specific to the IR receiver.  There is absolutely 
nothing in the pvrusb2 driver implementation that is in any way tied to 
the particular type of remote being used - all that information is 
contained only in the lirc conf file.  So you can easily substitute a 
different remote if you wanted, or even use multiple different types of 
remotes, all sharing the same IR receiver.  I've seen other V4L driver 
setups where the V4L driver tries to directly handle the IR reception on 
its own, tying into /dev/input in the kernel.  Unfortunately that approach 
seems to require that the remote-specific IR codes then have to be coded 
into the driver itself, which then ties your driver (and device hardware) 
to a specific remote.  I think that sucks :-)  Putting the IR decoding 
instead into a configurable userspace daemon (e.g. lirc) is a lot more 
flexible.

Disclaimer: I haven't studied lirc any more closely since about a year 
ago.  It just simply "works" so I haven't had a reason.  So perhaps there 
are improved choices possible now that I don't know about.

   -Mike

-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |