Linux Infrared Remote Control

Hi!

Bastien Nocera "hadess@..." wrote:
[...]
> I have a use case where lircd exiting when a device isn't available is a
> right pain.
[...]
> The attached patch seems to be enough to avoid lircd exiting, which
> means that it stays running in the background whenever a device is
> setup.

Why do you reject the connection anyway? Wouldn't the application show an  
error as well?

Would it help if lircd does not close the device once it has been opened?

Christoph

On Fri, 2008-08-15 at 14:27 +0200, Christoph Bartelmus wrote:
> Hi!
> 
> Bastien Nocera "hadess@..." wrote:
> [...]
> > I have a use case where lircd exiting when a device isn't available is a
> > right pain.
> [...]
> > The attached patch seems to be enough to avoid lircd exiting, which
> > means that it stays running in the background whenever a device is
> > setup.
> 
> Why do you reject the connection anyway? Wouldn't the application show an  
> error as well?

I don't quite understand. lircd exits because the connection is
rejected. The connection is rejected because there's no backing device.
Ie. the receiver isn't plugged in.

> Would it help if lircd does not close the device once it has been opened?

Not really, there's no device when we start up the application.

Hi!

Bastien Nocera "hadess@..." wrote:
> On Fri, 2008-08-15 at 14:27 +0200, Christoph Bartelmus wrote:
>> Hi!
>>
>> Bastien Nocera "hadess@..." wrote:
>> [...]
>>> I have a use case where lircd exiting when a device isn't available is a
>>> right pain.
>> [...]
>>> The attached patch seems to be enough to avoid lircd exiting, which
>>> means that it stays running in the background whenever a device is
>>> setup.
>>
>> Why do you reject the connection anyway? Wouldn't the application show an
>> error as well?

> I don't quite understand. lircd exits because the connection is
> rejected. The connection is rejected because there's no backing device.
> Ie. the receiver isn't plugged in.

Take a look at the code:
if(!hw.init_func())
{
        shutdown(clis[0],2);
        close(clis[0]);
        clin=0;
        dosigterm(SIGTERM);
}

Your patch comments out the dosigterm() call. The connection is still  
rejected. I don't see how it should make a difference to the application  
if the connection is just rejected or lircd is not running at all. The  
effect is the same for the application, i.e. no connection to lircd.

>> Would it help if lircd does not close the device once it has been opened?

> Not really, there's no device when we start up the application.

In the use case that you have posted it would make a difference. Once  
opened, lircd would never close the device.
Currently, if you unplug the receiver while there is a client connected,  
lircd will retry opening the device until it is available again.

Christoph

On Mon, 2008-08-18 at 08:21 +0200, Christoph Bartelmus wrote:
> Hi!
> 
> Bastien Nocera "hadess@..." wrote:
> > On Fri, 2008-08-15 at 14:27 +0200, Christoph Bartelmus wrote:
> >> Hi!
> >>
> >> Bastien Nocera "hadess@..." wrote:
> >> [...]
> >>> I have a use case where lircd exiting when a device isn't available is a
> >>> right pain.
> >> [...]
> >>> The attached patch seems to be enough to avoid lircd exiting, which
> >>> means that it stays running in the background whenever a device is
> >>> setup.
> >>
> >> Why do you reject the connection anyway? Wouldn't the application show an
> >> error as well?
> 
> > I don't quite understand. lircd exits because the connection is
> > rejected. The connection is rejected because there's no backing device.
> > Ie. the receiver isn't plugged in.
> 
> Take a look at the code:
> if(!hw.init_func())
> {
>         shutdown(clis[0],2);
>         close(clis[0]);
>         clin=0;
>         dosigterm(SIGTERM);
> }
> 
> Your patch comments out the dosigterm() call. The connection is still  
> rejected. I don't see how it should make a difference to the application  
> if the connection is just rejected or lircd is not running at all. The  
> effect is the same for the application, i.e. no connection to lircd.

The problem is that lirc_init() would fail in the second case (because
lircd isn't running anymore). In the first one, we'd get nicely
deconnected from the lirc daemon, as it refuses the connection slightly
later on.

> >> Would it help if lircd does not close the device once it has been opened?
> 
> > Not really, there's no device when we start up the application.
> 
> In the use case that you have posted it would make a difference. Once  
> opened, lircd would never close the device.
> Currently, if you unplug the receiver while there is a client connected,  
> lircd will retry opening the device until it is available again.

Well, it would help, but it would still exit when we try to connect and
the device is gone.

The main problem is that lircd exits at all. I don't mind how it fails.
The problem is that there's cases where the user has setup everything
properly, and lircd could be not running. The user has no way to restart
lircd without using either the command-line, or setting up the receiver
again in gnome-lirc-properties. And that's not what we want to see.

Bastien Nocera wrote:

> 
> The main problem is that lircd exits at all. I don't mind how it fails.
> The problem is that there's cases where the user has setup everything
> properly, and lircd could be not running. The user has no way to restart
> lircd without using either the command-line, or setting up the receiver
> again in gnome-lirc-properties. And that's not what we want to see.
> 

How about setup your udev so it automatically starts up lircd when the
receiver is plugged in. I am assuming a usb receiver here...

	.bill

> > >> Would it help if lircd does not close the device once it has been opened?
> > 
> > > Not really, there's no device when we start up the application.
> > 
> > In the use case that you have posted it would make a difference. Once  
> > opened, lircd would never close the device.
> > Currently, if you unplug the receiver while there is a client connected,  
> > lircd will retry opening the device until it is available again.
> 
> Well, it would help, but it would still exit when we try to connect and
> the device is gone.
> 
> The main problem is that lircd exits at all. I don't mind how it fails.
> The problem is that there's cases where the user has setup everything
> properly, and lircd could be not running. The user has no way to restart
> lircd without using either the command-line, or setting up the receiver
> again in gnome-lirc-properties. And that's not what we want to see.

If it makes any difference, I second the call to always keep lircd
running and maintaining clients connections regardless of connected
hardware or LIRC reloads.  

I believe end users will have many less problems setting up LIRC.  The
common case I see is people using MythTV and wanting to test a bunch of
lircd.conf files for transmitting (set-top boxes) - the average newbie
has to do an MS-style reboot to reload LIRC first then MythTV to test
their TX/channel changing script using their remote.

Would this also be a step to avoid having to have a separate lircrcd?

Matthew

On Mon, 2008-08-18 at 20:13 +0300, Vassilis Virvilis wrote:
> Bastien Nocera wrote:
> 
> > 
> > The main problem is that lircd exits at all. I don't mind how it fails.
> > The problem is that there's cases where the user has setup everything
> > properly, and lircd could be not running. The user has no way to restart
> > lircd without using either the command-line, or setting up the receiver
> > again in gnome-lirc-properties. And that's not what we want to see.
> > 
> 
> How about setup your udev so it automatically starts up lircd when the
> receiver is plugged in. I am assuming a usb receiver here...

I'm looking at a more generic solution to include in a distribution, so
the receiver could very well be serial, or something else...

I've already got plans to add a udev hook for USB lirc devices to be
automatically setup with gnome-lirc-properties if the configuration
hasn't been modified, and it's the only receiver.

On Mon, 2008-08-18 at 15:07 -0400, Matthew Bodkin wrote:
> > > >> Would it help if lircd does not close the device once it has been opened?
> > > 
> > > > Not really, there's no device when we start up the application.
> > > 
> > > In the use case that you have posted it would make a difference. Once  
> > > opened, lircd would never close the device.
> > > Currently, if you unplug the receiver while there is a client connected,  
> > > lircd will retry opening the device until it is available again.
> > 
> > Well, it would help, but it would still exit when we try to connect and
> > the device is gone.
> > 
> > The main problem is that lircd exits at all. I don't mind how it fails.
> > The problem is that there's cases where the user has setup everything
> > properly, and lircd could be not running. The user has no way to restart
> > lircd without using either the command-line, or setting up the receiver
> > again in gnome-lirc-properties. And that's not what we want to see.
> 
> If it makes any difference, I second the call to always keep lircd
> running and maintaining clients connections regardless of connected
> hardware or LIRC reloads.  

Client connections being kept alive isn't such a problem for my use
case, but I certainly need lircd to be kept running...

Cheers

Hi,

I'm currently trying to get the Snapstream Firefly Mini to work 
corrcetly under Fedora 9 (FC9).

I have followed the steps here - 
http://www.mythtv.org/wiki/index.php/Snapstream_firefly_mini - and done 
the following:

1. yum install lirc lirc-libs lirc-lib-devel
2. /etc/sysconfig/lirc:
    LIRCD_OPTIONS="--driver=dev/input --device=/dev/input/firefly-mini 
--output=/dev/lircd --pidfile /var/run/lircd.pid"
3. /etc/udev/rules.d/10-local.rules:
    
KERNEL=="event*",ATTRS{modalias}=="usb:v1233pE006d0100dc00dsc00dp00ic03isc01ip01",SYMLINK="input/firefly-mini"
4. /sbin/chkconfig lirc on
5. /sbin/service lirc start

Now, after I plug in the USB receiver, /dev/input/firefly-mini is 
created, but if I do "/sbin/lsmod | grep lirc" I get nothing.
Shouldn't a lirc module be automatically loaded?


Now, if I start "irrecord --device=/dev/input/firefly-mini-mouse 
--driver=dev/input firefly-mini" I can get a lot of buttonpresses, but 
if I control-c the program and look into the file firefly-mini it's 
empty. No config written.
Also, if I start irw, I get no output whatsoever on console...

In short, I seem to hav set things up in a way, but it's only half way 
there. Reading from /dev/input/firefly-mini yields a lot of key-codes...

Lirc is verison 0.8.3.


Does anybody have any experience with this? Why doesn't irrecord create 
a config file...?
Greatful for any pointers.


Cheers,


-Morten

-- 
---------------------------------------------------
WEB-fx                      http://www.webfx.no
Morten Rønseth              morten.ronseth@...
Odinsvei 15c                +47 6680 9191
1413 Tårnåsen               +47 9343 4357

On Tue, 2008-08-19 at 21:01 +0200, Morten Rønseth wrote:
> Hi,
> 
> I'm currently trying to get the Snapstream Firefly Mini to work 
> corrcetly under Fedora 9 (FC9).
> 
> I have followed the steps here - 
> http://www.mythtv.org/wiki/index.php/Snapstream_firefly_mini - and done 
> the following:
> 
> 1. yum install lirc lirc-libs lirc-lib-devel
> 2. /etc/sysconfig/lirc:
>     LIRCD_OPTIONS="--driver=dev/input --device=/dev/input/firefly-mini 
> --output=/dev/lircd --pidfile /var/run/lircd.pid"
> 3. /etc/udev/rules.d/10-local.rules:
>     
> KERNEL=="event*",ATTRS{modalias}=="usb:v1233pE006d0100dc00dsc00dp00ic03isc01ip01",SYMLINK="input/firefly-mini"
> 4. /sbin/chkconfig lirc on
> 5. /sbin/service lirc start
> 
> Now, after I plug in the USB receiver, /dev/input/firefly-mini is 
> created, but if I do "/sbin/lsmod | grep lirc" I get nothing.
> Shouldn't a lirc module be automatically loaded?

No, not for a device that is accessed using the usb input layer.

> Now, if I start "irrecord --device=/dev/input/firefly-mini-mouse 
> --driver=dev/input firefly-mini" I can get a lot of buttonpresses, but 
> if I control-c the program and look into the file firefly-mini it's 
> empty. No config written.

If I recall correctly, it takes a while for irrecord to get enough data
to build a config file... Don't ctl-c it, keep going until it says its
done.

> Also, if I start irw, I get no output whatsoever on console...

irw requires an existing config in place to tell you what buttons it thinks were pressed.



-- 
Jarod Wilson
jarod@...

Jarod Wilson wrote:
> On Tue, 2008-08-19 at 21:01 +0200, Morten Rønseth wrote:
>   
>> Hi,
>>
>> I'm currently trying to get the Snapstream Firefly Mini to work 
>> corrcetly under Fedora 9 (FC9).
>>
>> I have followed the steps here - 
>> http://www.mythtv.org/wiki/index.php/Snapstream_firefly_mini - and done 
>> the following:
>>
>> 1. yum install lirc lirc-libs lirc-lib-devel
>> 2. /etc/sysconfig/lirc:
>>     LIRCD_OPTIONS="--driver=dev/input --device=/dev/input/firefly-mini 
>> --output=/dev/lircd --pidfile /var/run/lircd.pid"
>> 3. /etc/udev/rules.d/10-local.rules:
>>     
>> KERNEL=="event*",ATTRS{modalias}=="usb:v1233pE006d0100dc00dsc00dp00ic03isc01ip01",SYMLINK="input/firefly-mini"
>> 4. /sbin/chkconfig lirc on
>> 5. /sbin/service lirc start
>>
>> Now, after I plug in the USB receiver, /dev/input/firefly-mini is 
>> created, but if I do "/sbin/lsmod | grep lirc" I get nothing.
>> Shouldn't a lirc module be automatically loaded?
>>     
>
> No, not for a device that is accessed using the usb input layer.
>
>   
>> Now, if I start "irrecord --device=/dev/input/firefly-mini-mouse 
>> --driver=dev/input firefly-mini" I can get a lot of buttonpresses, but 
>> if I control-c the program and look into the file firefly-mini it's 
>> empty. No config written.
>>     
>
> If I recall correctly, it takes a while for irrecord to get enough data
> to build a config file... Don't ctl-c it, keep going until it says its
> done.
>
>   
>> Also, if I start irw, I get no output whatsoever on console...
>>     
>
> irw requires an existing config in place to tell you what buttons it thinks were pressed.
>
>
>
>   
Thanks, that got irrecord going!
Alas, all codes in the config file have same value, namely "0x00040004". 
Any idea?

Another thing while I'm at it - this remote has a keyboard and a mouse 
(logically) and the device I'm currently reading from only gets keyboard 
codes.
How do I go about setting things up so I get both mouse & keyboard? Do I 
use same setup for mouse ? I.e. do I use something like:

    KERNEL=="event*",ATTRS{modalias}=="usb:v1233pE006d0100dc00dsc00dp00ic03isc01ip02",SYMLINK="input/firefly-mini-mouse"

    And then:

    LIRCMD_OPTIONS="--driver=dev/input
    --device=/dev/input/firefly-mini-mouse --output=/dev/lircd --pidfile
    /var/run/lircd.pid"

Will that work?



Thanks!



Cheers,


-Morten

-- 
---------------------------------------------------
WEB-fx                      http://www.webfx.no
Morten Rønseth              morten.ronseth@...
Odinsvei 15c                +47 6680 9191
1413 Tårnåsen               +47 9343 4357

On Tue, 2008-08-19 at 21:01 +0200, Morten Rønseth wrote:
> Hi,

Don't start new threads by replying to old ones! This has nothing to do
with lircd exiting.

FWIW, I'd do:
yum --enablerepo=rawhide install gnome-lirc-properties

(Make sure you have the latest PolicyKit updates on your system)

And after a restart, you should be able to use gnome-lirc-properties to
setup your remote without poking at stuff by hand.

Hi!

Bastien Nocera "hadess@..." wrote:

> On Mon, 2008-08-18 at 15:07 -0400, Matthew Bodkin wrote:
>>>>>> Would it help if lircd does not close the device once it has been
>>>>>> opened?
>>>>
>>>>> Not really, there's no device when we start up the application.
>>>>
>>>> In the use case that you have posted it would make a difference. Once
>>>> opened, lircd would never close the device.
>>>> Currently, if you unplug the receiver while there is a client connected,
>>>> lircd will retry opening the device until it is available again.
>>>
>>> Well, it would help, but it would still exit when we try to connect and
>>> the device is gone.
>>>
>>> The main problem is that lircd exits at all. I don't mind how it fails.
>>> The problem is that there's cases where the user has setup everything
>>> properly, and lircd could be not running. The user has no way to restart
>>> lircd without using either the command-line, or setting up the receiver
>>> again in gnome-lirc-properties. And that's not what we want to see.
>>
>> If it makes any difference, I second the call to always keep lircd
>> running and maintaining clients connections regardless of connected
>> hardware or LIRC reloads.

> Client connections being kept alive isn't such a problem for my use
> case, but I certainly need lircd to be kept running...

Currently lircd will exit if the device is not available and the 1st  
client connects.

If a client already is connected and the device becomes unavailable, the  
2nd client will be able to connect without any problem.

This is kind of inconsistent and I would propose to change the code that  
the 1st client will be able connect regardless whether the device can be  
opened or not.

Christoph

On Tue, 2008-08-19 at 22:20 +0200, Christoph Bartelmus wrote:
<snip>
> Currently lircd will exit if the device is not available and the 1st  
> client connects.
> 
> If a client already is connected and the device becomes unavailable, the  
> 2nd client will be able to connect without any problem.
> 
> This is kind of inconsistent and I would propose to change the code that  
> the 1st client will be able connect regardless whether the device can be  
> opened or not.

So we should make sure that lircd always keeps running, and never
disconnects whether the backing device is available or not. Is that
correct?

Removing that whole chunk of code around the patch I proposed at the
beginning of the thread should fix the problem. Is that what you would
want? If so, I'll make a patch and test it tomorrow.

Cheers

Hi!

Bastien Nocera "hadess@..." wrote:

> On Tue, 2008-08-19 at 22:20 +0200, Christoph Bartelmus wrote:
> <snip>
>> Currently lircd will exit if the device is not available and the 1st
>> client connects.
>>
>> If a client already is connected and the device becomes unavailable, the
>> 2nd client will be able to connect without any problem.
>>
>> This is kind of inconsistent and I would propose to change the code that
>> the 1st client will be able connect regardless whether the device can be
>> opened or not.

> So we should make sure that lircd always keeps running, and never
> disconnects whether the backing device is available or not. Is that
> correct?
>
> Removing that whole chunk of code around the patch I proposed at the
> beginning of the thread should fix the problem. Is that what you would
> want? If so, I'll make a patch and test it tomorrow.

Yes, that's what I currently have in mind if somebody does not find any  
good arguments against it.

Christoph

On Tue, 2008-08-19 at 23:08 +0200, Christoph Bartelmus wrote:
> Hi!
> 
> Bastien Nocera "hadess@..." wrote:
> 
> > On Tue, 2008-08-19 at 22:20 +0200, Christoph Bartelmus wrote:
> > <snip>
> >> Currently lircd will exit if the device is not available and the 1st
> >> client connects.
> >>
> >> If a client already is connected and the device becomes unavailable, the
> >> 2nd client will be able to connect without any problem.
> >>
> >> This is kind of inconsistent and I would propose to change the code that
> >> the 1st client will be able connect regardless whether the device can be
> >> opened or not.
> 
> > So we should make sure that lircd always keeps running, and never
> > disconnects whether the backing device is available or not. Is that
> > correct?
> >
> > Removing that whole chunk of code around the patch I proposed at the
> > beginning of the thread should fix the problem. Is that what you would
> > want? If so, I'll make a patch and test it tomorrow.
> 
> Yes, that's what I currently have in mind if somebody does not find any  
> good arguments against it.

The attached patch seems to work as expected.

Cheers

Hi!

Bastien Nocera "hadess@..." wrote:
[...]
>>> Removing that whole chunk of code around the patch I proposed at the
>>> beginning of the thread should fix the problem. Is that what you would
>>> want? If so, I'll make a patch and test it tomorrow.
>>
>> Yes, that's what I currently have in mind if somebody does not find any
>> good arguments against it.

> The attached patch seems to work as expected.

Applied.

Christoph