From: Tobias A. <to...@xb...> - 2008-05-20 18:50:02
|
Hi I'm a developer for XBMC for Linux and we use LIRC but we have a bit of trouble with standby and LIRC. We use the standard socket procedure with a nonblocking socket. The main problem for us is that we have no way of knowing if we lost connection to lirc, no IO error when we enter a standby. I suspect we might not loose connection but lirc doesn't seem to recognize us as it doesn't send anything on the socket. To fix this we reinitialize, which works. The problem is to recognize when we need to do this because lirc exhibit the same behavior if a user have gone into a sleep-wake cycle or if they've unplugged the hardware. User A no button press errno 11, and recv -1 Button press gives returns >= 0 errno = 0 -sleep- no button press errno gives 0, recv 0. button press errno gives 0, recv 0. User B (has no remote at all) errno gives 0, recv 0. I feel it's bad design to disable lirc after X failed reinitializes (so User B doesn't go into reinitialize over and over again) mainly because hotpluggable wouldn't be possible? So what I'm asking is: Is there any small ping packet or connect packet XBMC always could send so User A never gets into trouble? We run this on Ubuntu, same behavior on hardy and gutsy sincerely Topfs2 |
From: Tobias A. <to...@xb...> - 2008-05-18 23:53:46
|
Hi I'm a developer for XBMC for linux and we use LIRC but we have a bit of trouble with standby and LIRC. We use the standard socket procedure with a nonblocking socket. The main problem for us is that we have no way of knowing if we lost connection to lirc, no IO error when we enter a standby. I suspect we might not loose connection but lirc doesn't seem to recognise us as it doesn't send anything on the socket. To fix this we reinitialize, which works. The problem is to recognise when we need to do this because lirc exhibit the same behaviour if a user have gone into a sleep-wake cycle or if the've unplugged the hw. User A no button press errno 11, and recv -1 Button press gives returns >= 0 errno = 0 -sleep- no button press errno gives 0, recv 0. button press errno gives 0, recv 0. User B (has no remote at all) errno gives 0, recv 0. I feel it's bad design to disable lirc after X failed reinitalizes (so User B doesn't go into reinitialize over and over again) mainly because hotpluggable wouldn't be possible? So what I'm asking is: Is there any small ping packet or connect packet XBMC always could send so User A never gets into trouble? sincerely Topfs2 |
From: <li...@ba...> - 2008-05-20 19:07:20
|
Hi! Tobias Arrskog "to...@xb..." wrote: > Hi I'm a developer for XBMC for Linux and we use LIRC but we have a bit of > trouble with standby and LIRC. [...] > So what I'm asking is: Is there any small ping packet or connect packet XBMC > always could send so User A never gets into trouble? No, and it most likely wouldn't solve your problem anyway because I don't think you lose connection to lircd, but lircd might lose connection to the hardware. I guess that there might be a problem with certain types of hardware only, where lircd would have to reinitialize the hardware after coming back from standby. So please describe your setup in more detail. Here, with a Streamzap receiver, I can unplug/replug the device and even do a suspend to disk/resume, and the remote will work almost immediately afterwards. Christoph |
From: Tino K. <tin...@ti...> - 2008-05-21 15:59:29
|
On Tue, May 20, 2008 at 20:49:59 +0200, Tobias Arrskog wrote: > Hi I'm a developer for XBMC for Linux and we use LIRC but we have a bit of > trouble with standby and LIRC. > We use the standard socket procedure with a nonblocking socket. The main > problem for us is that we have no way of knowing if we lost connection to > lirc, no IO error when we enter a standby. I suspect we might not loose > connection but lirc doesn't seem to recognize us as it doesn't send anything > on the socket. To fix this we reinitialize, which works. The problem is to > recognize when we need to do this because lirc exhibit the same behavior if > a user have gone into a sleep-wake cycle or if they've unplugged the > hardware. I once used LIRC hardware with drivers that needed to be reloaded after suspend. All LIRC clients also needed to be reloaded, which I wanted to avoid. As a solution, I added a LIRC meta daemon, so I had 2 lircd processes running on one computer. Then, the LIRC daemon that handled the hardware send the events to the meta LIRC daemon, and the clients connected to the meta daemon. After suspend, I restarted the hardware daemon, and the clients didn't need to be restarted to work after suspend, because the didn't lose the connection to their meats LIRC daemon. Regards, Tino |
From: Tobias A. <to...@xb...> - 2008-05-21 18:27:54
|
>From what I've noticed the lircd doesn't need to be reinitialized just the connection (Although it might be automatic on ubuntu which would explain alot, is it a "known" bug?) There is nothing I can send to lircd over the socket that would force it to send something back? If it can't send stuff back I'd know it lost the connection, and that would be enough. Thanks for the reply! Sincerely Topfs2 On Wed, May 21, 2008 at 6:00 PM, Tino Keitel <tin...@ti...<tino.keitel%2B...@ti...>> wrote: > On Tue, May 20, 2008 at 20:49:59 +0200, Tobias Arrskog wrote: > > Hi I'm a developer for XBMC for Linux and we use LIRC but we have a bit > of > > trouble with standby and LIRC. > > We use the standard socket procedure with a nonblocking socket. The main > > problem for us is that we have no way of knowing if we lost connection to > > lirc, no IO error when we enter a standby. I suspect we might not loose > > connection but lirc doesn't seem to recognize us as it doesn't send > anything > > on the socket. To fix this we reinitialize, which works. The problem is > to > > recognize when we need to do this because lirc exhibit the same behavior > if > > a user have gone into a sleep-wake cycle or if they've unplugged the > > hardware. > > I once used LIRC hardware with drivers that needed to be reloaded after > suspend. All LIRC clients also needed to be reloaded, which I wanted to > avoid. As a solution, I added a LIRC meta daemon, so I had 2 lircd > processes running on one computer. Then, the LIRC daemon that handled > the hardware send the events to the meta LIRC daemon, and the clients > connected to the meta daemon. After suspend, I restarted the hardware > daemon, and the clients didn't need to be restarted to work after > suspend, because the didn't lose the connection to their meats LIRC > daemon. > > Regards, > Tino > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > |
From: Wayne R. <wa...@no...> - 2008-05-21 21:38:24
|
I have now been trying for a while, without any success to get my MCE remote to work with lirc Here are my details dmesg | grep lirc lirc_dev: IR Remote Control driver registered, major 61 lirc_mceusb2: Philips eHome USB IR Transceiver and Microsoft MCE 2005 Remote Control driver for LIRC $Revision: 1.44 $ lirc_mceusb2: Daniel Melander <li...@ra...>, Martin Blatter <mar...@ya...> usbcore: registered new interface driver lirc_mceusb2 usbcore: deregistering interface driver lirc_mceusb2 lirc_mceusb2: Philips eHome USB IR Transceiver and Microsoft MCE 2005 Remote Control driver for LIRC $Revision: 1.44 $ lirc_mceusb2: Daniel Melander <li...@ra...>, Martin Blatter <mar...@ya...> usbcore: registered new interface driver lirc_mceusb2 modeprobe.conf alias eth0 e1000e alias sound-slot-0 snd_emu10k1 install scsi_hostadapter /sbin/modprobe ahci; /sbin/modprobe ata_piix; /sbin/modprobe pata_marvell; /sbin/modprobe usb_storage; /bin/true install usb-interface /sbin/modprobe uhci_hcd; /sbin/modprobe ehci_hcd; /bin/true alias ieee1394-controller ohci1394 alias pci:v00008086d0000104Asv00008086sd00000001bc02sc00i00 e1000 alias char-major-61 lirc_mceusb2 remove snd_emu10k1 /sbin/modprobe --first-time -r --ignore-remove snd_emu10k1 install snd_emu10k1 /sbin/modprobe --first-time --ignore-install snd_emu10k1 remove audigy /sbin/modprobe --first-time -r --ignore-remove audigy install audigy /sbin/modprobe --first-time --ignore-install audigy /etc/sysconfig/lircd # Customized setings for lirc daemon # The hardware driver to use, run lircd --driver=? for a list DRIVER=default # Hardware driver module to load HWMOD=lirc_mceusb2 # The device node that communicates with the IR device. # if you are using lirc_serial, set DEVICE to /dev/ttyS[0-9] # where 0-9 is the serial port your IR receiver is plugged # with devfs enabled #DEVICE=/dev/lirc/0 #DEVICE=/dev/lirc/serial # without devfs DEVICE=/dev/lirc # Serial port for the receiver (for serial driver) # COM1 (/dev/ttyS0) #COM_PORT=/dev/ttyS0 #DRIVER_OPTS="irq=4 io=0x3f8" # COM2 (/dev/ttyS1) #COM_PORT=/dev/ttyS1 #DRIVER_OPTS="irq=3 io=0x2f8" # COM3 (/dev/ttyS2) #COM_PORT=/dev/ttyS2 #DRIVER_OPTS="irq=4 io=0x3e8 # COM4 (/dev/ttyS3) #COM_PORT=/dev/ttyS3 #DRIVER_OPTS="irq=3 io=0x2e8" And lastly lsusb shows lsusb Bus 002 Device 001: ID 1d6b:0002 Bus 007 Device 001: ID 1d6b:0001 Bus 006 Device 002: ID 0471:0608 Philips Bus 006 Device 001: ID 1d6b:0001 Bus 005 Device 001: ID 1d6b:0001 Bus 001 Device 001: ID 1d6b:0002 Bus 004 Device 001: ID 1d6b:0001 Bus 003 Device 001: ID 1d6b:0001 Everything here seems fine (but obviously not) but when I run irw to test I get: irw connect: Connection refused what I do notice is that a lot of the forums refer to a device in /dev/lircd/"Some or other Number" which I have never gotten I have tried this on Ubuntu and Mandriva but no luck at all Mandriva is my choice distro and found another awesome page dedicated to mandriva users and lirc but the howto is for serial device and I cannot seem to get the mceusb2 to work using it. Please I need help __________ Information from ESET NOD32 Antivirus, version of virus signature database 3118 (20080521) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |