Linux infrared remote control ()

Henning Glawe | 1 Nov 2009 02:09

Re: [Patch] Driver and configuration for the Philips SRM 7500 RF remote

>On Sat, Oct 31, 2009 at 15:32:00PM +0100, Christoph wrote:
>Henning Glawe "glaweh@..." wrote:
>> + logprintf(LOG_ERR, "Error reading from usb worker process");
>> + if(rd <= 0 && errno != EINTR) raise(SIGTERM);
>
>Instead of raise(SIGTERM), call srm7500_deinit() here.

changed in new version of the driver. But: if we do not kill lircd at this
point, how can clients recover? if any client is still attached to lircd, the
receiver will not be reinitialized...

>> + code = 0x80010000;
>
>Get rid of this 0x8001 constant. It's meaningless.
>Just remove pre_data and pre_data_bits from the config file.

done. actually, this was a remainder of the hw_devinput code I forgot to
clean up.

>> + if(rccode[2] == 3) return NULL;
>
>What's the meaning of '3'?

it is the key-up event sent by the remote. documented in new version of the
driver (by introducing named constants).

>Would it make sense to add the rccode[2] field to the code?

I am not sure; rccode[2]==1 means button press, rccode[2]==2 means key repeat
(which the driver treats like in devinput by communicating the repeat flag

(Continue reading)

headers

Jarod Wilson | 1 Nov 2009 03:30

Re: PVR-150 IR blaster with 2.6.31 Karmic Koala kernel

On 10/31/2009 01:01 PM, Trevor Bradley wrote:
> Hey there.. I've been using a modded version of lirc 0.8.5 with my
> Hauppauge PVR-150's IR blaster for a while here:
> http://www.blushingpenguin.com/mark/blog/?p=24. I have an older PVR-150
> card with it's IR blaster taped to the front of my cable box. The IR
> blaster is the type with a cable that plugs directly into the back of
> the PVR-150.
>
> It's worked great for the past couple years on Slackware and then later
> Ubuntu, but after my update to Ubuntu Karmic Koala in the past few days,
> the modded lirc 0.8.5 no longer compiles with Karmic's 2.6.31 kernel.

Yep, 2.6.31 introduced some major i2c changes.

> I thought of backtracking and booting Karmic with an older kernel, but
> Karmic's upgrade of gcc means that drivers can't be compiled against the
> older kernel, so that option is out.

Horsefeathers.

...
> Now perhaps the obvious thing to do here is be patient and wait for Mark
> to put out a 0.8.6 update, but I've emailed him and it's possible he's
> not actively updating anymore. Another option is to hunt around for a
> cheap IR blaster to replace the PVR-150's blaster, but I'm not sure what
> the cheapest/most compatible option is here. Or I could attempt to
> fiddle around with Mark's patch further and try to figure out what's
> wrong... unfortunately I've been sick and software patching and
> debugging isn't my thing right now.

(Continue reading)

headers

Trevor Bradley | 1 Nov 2009 05:30

Re: PVR-150 IR blaster with 2.6.31 Karmic Koala kernel

Jarod Wilson wrote:
> I've been maintaining a version of lirc_pvr150, renamed lirc_zilog, in 
> my git tree for quite some time now. Its long since been updated to 
> function with 2.6.31 (among other things -- also works with the HD 
> PVR). I've already talked to Mario Limonciello, and I believe he's 
> thinking about throwing together a dkms package for Ubuntu users.
>
> In the short term, you can grab this:
>
> http://wilsonet.com/jarod/junk/lirc-snap-20091027.tar.bz2
>
> Unpack it, cd into the unpacked directory, then:
>
> $ make CONFIG_INPUT_LIRC=m CONFIG_LIRC_ZILOG=m -C 
> /usr/src/kernels/$(uname -r) M=$PWD modules
>
> (all on one line there)
>
> Then drop the resulting .ko files over the top of your existing ones, 
> or in a modprobe path of higher precedence, and run depmod. Then you 
> should be able to modprobe lirc_zilog and have a working setup again.
>
It worked!  12 years of Slackware experience helped here.

Here's a few hints for others who used Mark's lirc braindump before and 
are trying Jarod's lirc files on ubuntu...

1) /usr/src/kernels/$(uname -r) was in 
/lib/modules/2.6.31-14-generic-pae/ for me
2) my .ko files live in

(Continue reading)

headers

Christoph Bartelmus | 1 Nov 2009 08:14

Re: [Patch] Driver and configuration for the Philips SRM 7500 RF remote

Hi!

Henning Glawe "glaweh@..." wrote:

>> On Sat, Oct 31, 2009 at 15:32:00PM +0100, Christoph wrote:
>> Henning Glawe "glaweh@..." wrote:
>>> + logprintf(LOG_ERR, "Error reading from usb worker process");
>>> + if(rd <= 0 && errno != EINTR) raise(SIGTERM);
>>
>> Instead of raise(SIGTERM), call srm7500_deinit() here.

> changed in new version of the driver. But: if we do not kill lircd at this
> point, how can clients recover? if any client is still attached to lircd,
> the receiver will not be reinitialized...

The receiver will be reinitialized automatically by lircd.
Just try disconnecting and reconnecting the receiver. With all of my  
devices it will continue to work just as if nothing had happened.

>>> + if(rccode[2] == 3) return NULL;
>>
>> What's the meaning of '3'?

> it is the key-up event sent by the remote. documented in new version of the
> driver (by introducing named constants).

>> Would it make sense to add the rccode[2] field to the code?

> I am not sure; rccode[2]==1 means button press, rccode[2]==2 means key
> repeat (which the driver treats like in devinput by communicating the repeat

(Continue reading)

headers

Jed Lane | 2 Nov 2009 06:47

Which IR transceiver to get?

So anyone else have a preference they'd like to voice and why?!  

Thanks,
Jed

-------- Original Message --------
Well I've been doing some reading but I've gotten to a point where I
can't quite decide which transceiver to get.
I've narrowed it down to these four:

BC4+BCX-1 ---Bitwise Controls http://www.bitwisecontrols.com/products.php
IRTrans Ethernet
http://www.irtrans.de/en/shop/lan.php
CommandIR II
http://www.commandir.com/content/view/32/48/
USB-IR transceiver ---IguanaWorks
http://iguanaworks.net/

Global cache is ruled out as I've seen no mention of development for
Linux on their site.
Also I'm not sure the last one is really a contender because it's very
light on features compared to the others...

Then again, despite having many features the IRTrans device does have
one big knock against it that this one doesn't.
It's built-in transmitter only has one port....

This port can have up to 6 emitters, but you can only output the
*same* code-set simultaneously via those emitters.
A second port can be added, but even then one cannot transmit two

(Continue reading)

headers

Jed | 2 Nov 2009 06:49

Re: Which IR transceiver to get? CommandIR parallel blasting explained

>>>>>> Also, although  you can transmit on any combination of the (up to 
>>>>>> 4) emitters  simultaneously, you cannot transmit different codes 
>>>>>> on different  emitters simultaneously.
>>>>> The IRtrans model I'm considering is also limited in this way.
>>>>> It doesn't have CommandIR's "parallels device blasting"
>>>>> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
>>>>> I think it might be a bit of a gimmick though...
>>>> I'm not sure this is actually an issue in reality because I believe 
>>>> that lirc effectively pipelines send requests to the same device so 
>>>> if you tried to issue two irsend commands at the same time, one 
>>>> would end up waiting for the other to complete before transmitting 
>>>> -- worth verifying though.
>>> Yeah this is what was explained to me, so I'm not sure how CIR's 
>>> parallel device blasting would actually work in that case...
>>
>> Since I'm following the thread, hopefully I can help clarify.
>> The CommandIR driver is different from the others in that it doesn't use
>> separate LIRC instances / driver instantiations for each of the IR
>> blasters, always just 1, so it doesn't benefit from LIRC pipelining to
>> the driver. 
>> In order to transmit different signals on each emitter at the same time,
>> CommandIR has it's own pipe-lining.  Has to keep all the data streams
>> coming so the TX doesn't get starved.  There may be a better technical
>> way to do it now, but at the time each hardware device was assumed to
>> have 1 transmitter and 1 modulator.
>>
>> This design makes it real easy to officially support up to 16 IR
>> emitters (4 CommandIRs), since plugging in more CommandIRs is invisible
>> to LIRC and the user.  A couple of the well known US set-top-box
>> manufacturers use CommandIR arrays (and LIRC) for testing - without the

(Continue reading)

headers

Jed Lane | 2 Nov 2009 15:46

Which IR transceiver to get?

So anyone else have a preference they'd like to voice and why?!  

Thanks,
Jed

-------- Original Message --------
Well I've been doing some reading but I've gotten to a point where I
can't quite decide which transceiver to get.
I've narrowed it down to these four:

BC4+BCX-1 ---Bitwise Controls http://www.bitwisecontrols.com/products.php
IRTrans Ethernet
http://www.irtrans.de/en/shop/lan.php
CommandIR II
http://www.commandir.com/content/view/32/48/
USB-IR transceiver ---IguanaWorks
http://iguanaworks.net/

Global cache is ruled out as I've seen no mention of development for
Linux on their site.
Also I'm not sure the last one is really a contender because it's very
light on features compared to the others...

Then again, despite having many features the IRTrans device does have
one big knock against it that this one doesn't.
It's built-in transmitter only has one port....

This port can have up to 6 emitters, but you can only output the
*same* code-set simultaneously via those emitters.
A second port can be added, but even then one cannot transmit two

(Continue reading)

headers

Jed | 3 Nov 2009 14:52

Re: Which IR transceiver to get? CommandIR parallel blasting explained

>>>>>>> Also, although  you can transmit on any combination of the (up to 
>>>>>>> 4) emitters  simultaneously, you cannot transmit different codes 
>>>>>>> on different  emitters simultaneously.
>>>>>> The IRtrans model I'm considering is also limited in this way.
>>>>>> It doesn't have CommandIR's "parallels device blasting"
>>>>>> i.e. sending 4 diff. code-sets at once to 4 diff. devices.
>>>>>> I think it might be a bit of a gimmick though...
>>>>> I'm not sure this is actually an issue in reality because I believe 
>>>>> that lirc effectively pipelines send requests to the same device so 
>>>>> if you tried to issue two irsend commands at the same time, one 
>>>>> would end up waiting for the other to complete before transmitting 
>>>>> -- worth verifying though.
>>>> Yeah this is what was explained to me, so I'm not sure how CIR's 
>>>> parallel device blasting would actually work in that case...
>>>
>>> Since I'm following the thread, hopefully I can help clarify.
>>> The CommandIR driver is different from the others in that it doesn't use
>>> separate LIRC instances / driver instantiations for each of the IR
>>> blasters, always just 1, so it doesn't benefit from LIRC pipelining to
>>> the driver. In order to transmit different signals on each emitter at 
>>> the same time,
>>> CommandIR has it's own pipe-lining.  Has to keep all the data streams
>>> coming so the TX doesn't get starved.  There may be a better technical
>>> way to do it now, but at the time each hardware device was assumed to
>>> have 1 transmitter and 1 modulator.
>>>
>>> This design makes it real easy to officially support up to 16 IR
>>> emitters (4 CommandIRs), since plugging in more CommandIRs is invisible
>>> to LIRC and the user.  A couple of the well known US set-top-box
>>> manufacturers use CommandIR arrays (and LIRC) for testing - without the

(Continue reading)

headers

Jed | 3 Nov 2009 15:36

Which IR transceiver to get?

Well I've been doing some reading but I've gotten to a point where I can't quite decide which transceiver to get.
I've narrowed it down to these four:

BC4+BCX-1 ---Bitwise Controls http://www.bitwisecontrols.com/products.php
IRTrans Ethernet http://www.irtrans.de/en/shop/lan.php
CommandIR II http://www.commandir.com/content/view/32/48/
USB-IR transceiver ---IguanaWorks http://iguanaworks.net/

Global cache is ruled out as I've seen no mention of development for Linux on their site.
Also I'm not sure the last one is really a contender because it's very light on features compared to the others...

Then again, despite having many features the IRTrans device does have one big knock against it that this one doesn't.
It's built-in transmitter only has one port....

This port can have up to 6 emitters, but you can only output the same code-set simultaneously via those emitters.
A second port can be added, but even then one cannot transmit two different code-sets from the two ports (via emitters) at the same time!

I'd love to hear peoples thoughts/experiences surrounding these devices, which you'd recommend and why!

Thanks heaps,
Jed

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

headers

CommandIR Support | 3 Nov 2009 19:39

Re: Which IR transceiver to get?

On Tue, 2009-11-03 at 23:52 +1000, Jed wrote: 
> >> Was away for a few days, thanks for clarifying this!
> >> Still not quite sure this would benefit me in any way...
> >>
> >> I intend to learn all my consumer electronics IR codes using a 
> >> transceiver + LIRC. Then I hope to use a Wifi Hand-held + HTPC + LIRC 
> >> + Transceiver to issue commands to all gear within range.
> > 
> > Matt, could you explain how this might be advantageous for my usage 
> > scenario?  Thanks!
> > 
> > Cheers,
> > Jed
> 
> Hi Matt,
> 
> Could I possibly get a response?
> 
> Thank-you,
> Jed

Not more than I've already sent you on and off list.  Please feel free
to make both our jobs easier and scratch CommandIR from your shortlist.
I think you could have bought and tried all 4 products for the amount of
time you're spending reaching a conclusion.

All the best,

Matthew

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

24	May 2013
22	April 2013
15	March 2013
17	February 2013
12	January 2013
18	December 2012
17	November 2012
10	October 2012
4	September 2012
18	August 2012
21	July 2012
15	June 2012
25	May 2012
49	April 2012
28	March 2012
43	February 2012
23	January 2012
24	December 2011
25	November 2011
32	October 2011
20	September 2011
38	August 2011
53	July 2011
72	June 2011
226	May 2011
225	April 2011
129	March 2011
84	February 2011
85	January 2011
152	December 2010
153	November 2010
189	October 2010
123	September 2010
97	August 2010
99	July 2010
44	June 2010
71	May 2010
111	April 2010
86	March 2010
127	February 2010
104	January 2010
160	December 2009
168	November 2009
97	October 2009
117	September 2009
308	August 2009
204	July 2009
129	June 2009
95	May 2009
66	April 2009
102	March 2009
93	February 2009
192	January 2009
71	December 2008
120	November 2008
146	October 2008
252	September 2008
73	August 2008
59	July 2008
85	June 2008
120	May 2008
80	April 2008
57	March 2008
93	February 2008
123	January 2008
100	December 2007
97	November 2007
105	October 2007
135	September 2007
132	August 2007
160	July 2007
116	June 2007
108	May 2007
164	April 2007
116	March 2007
110	February 2007
167	January 2007
155	December 2006
132	November 2006
187	October 2006
103	September 2006
77	August 2006
119	July 2006
82	June 2006
110	May 2006
75	April 2006
102	March 2006
103	February 2006
148	January 2006
111	December 2005
113	November 2005
115	October 2005
143	September 2005
180	August 2005
109	July 2005
151	June 2005
100	May 2005
115	April 2005
166	March 2005
168	February 2005
199	January 2005
189	December 2004
154	November 2004
141	October 2004
174	September 2004
116	August 2004
76	July 2004
101	June 2004
112	May 2004
206	April 2004
246	March 2004
151	February 2004

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30