Henning Glawe | 1 Nov 02:09 2009
Picon

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)

Jarod Wilson | 1 Nov 03:30 2009

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)

Trevor Bradley | 1 Nov 05:30 2009
Picon
Picon

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)

Christoph Bartelmus | 1 Nov 08:14 2009
Picon

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)

Jed Lane | 2 Nov 06:47 2009
Picon

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)

Jed | 2 Nov 06:49 2009
Picon

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)

Jed Lane | 2 Nov 15:46 2009
Picon

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)

Jed | 3 Nov 14:52 2009
Picon

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)

Jed | 3 Nov 15:36 2009
Picon

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
CommandIR Support | 3 Nov 19:39 2009

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


Gmane