From: Bastien N. <ha...@ha...> - 2008-08-14 09:07:50
Attachments:
lirc-dont-exit.patch
|
Heya, I have a use case where lircd exiting when a device isn't available is a right pain. 1. Launch newly installed machine 2. Plug in USB receiver for the remote 3. Set it up using gnome-lirc-properties 4. Use happily with applications 5. Unplug receiver 6. Launch application, no worries, no lirc support but no receiver 7. Launch application again, lircd has quit in between, my application gives me an error! 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. What do you reckon? Cheers |
From: <li...@ba...> - 2008-08-15 12:33:43
|
Hi! Bastien Nocera "ha...@ha..." 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 |
From: Bastien N. <ha...@ha...> - 2008-08-17 21:08:49
|
On Fri, 2008-08-15 at 14:27 +0200, Christoph Bartelmus wrote: > Hi! > > Bastien Nocera "ha...@ha..." 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. |
From: <li...@ba...> - 2008-08-18 06:24:40
|
Hi! Bastien Nocera "ha...@ha..." wrote: > On Fri, 2008-08-15 at 14:27 +0200, Christoph Bartelmus wrote: >> Hi! >> >> Bastien Nocera "ha...@ha..." 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 |
From: Bastien N. <ha...@ha...> - 2008-08-18 09:50:11
|
On Mon, 2008-08-18 at 08:21 +0200, Christoph Bartelmus wrote: > Hi! > > Bastien Nocera "ha...@ha..." wrote: > > On Fri, 2008-08-15 at 14:27 +0200, Christoph Bartelmus wrote: > >> Hi! > >> > >> Bastien Nocera "ha...@ha..." 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. |
From: Vassilis V. <va...@ii...> - 2008-08-18 17:14:07
|
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 |
From: Bastien N. <ha...@ha...> - 2008-08-19 15:46:04
|
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. |
From: Matthew B. <li...@in...> - 2008-08-18 19:08:03
|
> > >> 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 |
From: Bastien N. <ha...@ha...> - 2008-08-19 15:47:37
|
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 |
From: <li...@ba...> - 2008-08-19 20:22:25
|
Hi! Bastien Nocera "ha...@ha..." 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 |
From: Bastien N. <ha...@ha...> - 2008-08-19 20:55:09
|
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 |
From: <li...@ba...> - 2008-08-19 21:09:39
|
Hi! Bastien Nocera "ha...@ha..." 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 |
From: Bastien N. <ha...@ha...> - 2008-08-21 11:11:55
Attachments:
lirc-dont-exit-2.patch
|
On Tue, 2008-08-19 at 23:08 +0200, Christoph Bartelmus wrote: > Hi! > > Bastien Nocera "ha...@ha..." 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 |
From: <li...@ba...> - 2008-08-21 18:58:23
|
Hi! Bastien Nocera "ha...@ha..." 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 |
From: Morten R. <mor...@we...> - 2008-08-19 19:01:12
|
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 mor...@we... Odinsvei 15c +47 6680 9191 1413 Tårnåsen +47 9343 4357 |
From: Jarod W. <ja...@wi...> - 2008-08-19 19:07:50
|
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 ja...@wi... |
From: Morten R. <mor...@we...> - 2008-08-19 19:22:41
|
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 mor...@we... Odinsvei 15c +47 6680 9191 1413 Tårnåsen +47 9343 4357 |
From: Bastien N. <ha...@ha...> - 2008-08-19 20:19:55
|
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. |