From: Greg O. <oli...@gm...> - 2010-01-17 00:50:08
|
I am fairly (well VERY) new to lirc... Just a quick question - am I correct in assuming lirc_mceusb currently encompasses all mce devices (even the numerous mceusb2) devices from 1.5 years ago.? If so, I have a device Topseed 0x0008 that I cannot get to transmit that receives just fine. Can someone point me in the right direction on troubleshooting? Thanks, Greg |
From: Jarod W. <ja...@wi...> - 2010-01-17 04:02:23
|
On Sat, Jan 16, 2010 at 7:50 PM, Greg Oliver <oli...@gm...> wrote: > I am fairly (well VERY) new to lirc... Just a quick question - am I > correct in assuming lirc_mceusb currently encompasses all mce devices > (even the numerous mceusb2) devices from 1.5 years ago.? See my reply on the mythtv-users lists to your same question. The answer isn't that hard to figure out if you just do a little bit of reading... > If so, I have a device Topseed 0x0008 that I cannot get to transmit > that receives just fine. Can someone point me in the right direction > on troubleshooting? Try altering its presence or non-presence in the inverted transmit mask list for a first step, that seems to be the most common cause of transmit failure. -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-01-17 15:12:06
|
On Sat, Jan 16, 2010 at 10:02 PM, Jarod Wilson <ja...@wi...> wrote: > On Sat, Jan 16, 2010 at 7:50 PM, Greg Oliver <oli...@gm...> wrote: >> I am fairly (well VERY) new to lirc... Just a quick question - am I >> correct in assuming lirc_mceusb currently encompasses all mce devices >> (even the numerous mceusb2) devices from 1.5 years ago.? > > See my reply on the mythtv-users lists to your same question. The > answer isn't that hard to figure out if you just do a little bit of > reading... > >> If so, I have a device Topseed 0x0008 that I cannot get to transmit >> that receives just fine. Can someone point me in the right direction >> on troubleshooting? > > Try altering its presence or non-presence in the inverted transmit > mask list for a first step, that seems to be the most common cause of > transmit failure. Thanks, I saw 1 thread from someone else regarding that where you replied. Is that as simple as just removing it from: usb_device_id transmitter_mask_list in the code? My device is already listed there, so I assumed so and tried it. { USB_DEVICE(VENDOR_TOPSEED, 0x0008) }, Still no joy! Arghhhh... The dev entry for the transmitter socket is not getting created. I think this may be the main issue: could not get file information for /dev/lirc1 Jan 17 09:00:46 htpc lircd-0.8.6[9420]: default_init(): No such file or directory Jan 17 09:00:46 htpc lircd-0.8.6[9420]: Failed to initialize hardware If I mknod the device, it still does not work though. Jan 17 09:08:16 htpc lircd-0.8.6[9512]: accepted new client on /var/run/lirc/lircd1 Jan 17 09:08:16 htpc lircd-0.8.6[9512]: could not open /dev/lirc1 Jan 17 09:08:16 htpc lircd-0.8.6[9512]: default_init(): Device or resource busy crw-rw---- 1 root root 61, 0 2010-01-17 08:46 /dev/lirc0 crw-rw---- 1 root root 61, 0 2010-01-17 09:07 /dev/lirc1 lrwxrwxrwx 1 root root 19 2010-01-17 09:07 /dev/lircd -> /var/run/lirc/lircd lrwxrwxrwx 1 root root 20 2010-01-17 09:07 /dev/lircd1 -> /var/run/lirc/lircd1 I am trying with : irsend SET_TRANSMITTERS 1 irsend SET_TRANSMITTERS 2 irsend SET_TRANSMITTERS 1 2 Always get irsend: hardware does not support sending Thanks, Greg |
From: Jarod W. <ja...@wi...> - 2010-01-17 15:58:54
|
On Sun, Jan 17, 2010 at 10:11 AM, Greg Oliver <oli...@gm...> wrote: > On Sat, Jan 16, 2010 at 10:02 PM, Jarod Wilson <ja...@wi...> wrote: >> On Sat, Jan 16, 2010 at 7:50 PM, Greg Oliver <oli...@gm...> wrote: >>> I am fairly (well VERY) new to lirc... Just a quick question - am I >>> correct in assuming lirc_mceusb currently encompasses all mce devices >>> (even the numerous mceusb2) devices from 1.5 years ago.? >> >> See my reply on the mythtv-users lists to your same question. The >> answer isn't that hard to figure out if you just do a little bit of >> reading... >> >>> If so, I have a device Topseed 0x0008 that I cannot get to transmit >>> that receives just fine. Can someone point me in the right direction >>> on troubleshooting? >> >> Try altering its presence or non-presence in the inverted transmit >> mask list for a first step, that seems to be the most common cause of >> transmit failure. > > Thanks, I saw 1 thread from someone else regarding that where you > replied. Is that as simple as just removing it from: > > usb_device_id transmitter_mask_list in the code? Yes, remove if present, add if not. > My device is already > listed there, so I assumed so and tried it. > > { USB_DEVICE(VENDOR_TOPSEED, 0x0008) }, > > Still no joy! Arghhhh... > > The dev entry for the transmitter socket is not getting created. The transmit side uses the same device as receive, it doesn't create a separate one. And for further clarification, the device entry isn't a socket, its an lirc device. The socket is /var/run/lirc/lircd, created by the lirc daemon, not by the driver. > I think this may be the main issue: > > could not get file information for /dev/lirc1 > Jan 17 09:00:46 htpc lircd-0.8.6[9420]: default_init(): No such file > or directory > Jan 17 09:00:46 htpc lircd-0.8.6[9420]: Failed to initialize hardware > > If I mknod the device, it still does not work though. Yeah, don't do that, you're doing it wrong. > Always get irsend: hardware does not support sending ...because you're trying to transmit via a non-existent device. Try using /dev/lirc0. Don't run a second lircd, one instance will handle everything. -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-01-17 16:23:53
|
On Sun, Jan 17, 2010 at 9:58 AM, Jarod Wilson <ja...@wi...> wrote: > On Sun, Jan 17, 2010 at 10:11 AM, Greg Oliver <oli...@gm...> wrote: >> On Sat, Jan 16, 2010 at 10:02 PM, Jarod Wilson <ja...@wi...> wrote: >>> On Sat, Jan 16, 2010 at 7:50 PM, Greg Oliver <oli...@gm...> wrote: >>>> I am fairly (well VERY) new to lirc... Just a quick question - am I >>>> correct in assuming lirc_mceusb currently encompasses all mce devices >>>> (even the numerous mceusb2) devices from 1.5 years ago.? >>> >>> See my reply on the mythtv-users lists to your same question. The >>> answer isn't that hard to figure out if you just do a little bit of >>> reading... >>> >>>> If so, I have a device Topseed 0x0008 that I cannot get to transmit >>>> that receives just fine. Can someone point me in the right direction >>>> on troubleshooting? >>> >>> Try altering its presence or non-presence in the inverted transmit >>> mask list for a first step, that seems to be the most common cause of >>> transmit failure. >> >> Thanks, I saw 1 thread from someone else regarding that where you >> replied. Is that as simple as just removing it from: >> >> usb_device_id transmitter_mask_list in the code? > > Yes, remove if present, add if not. > >> My device is already >> listed there, so I assumed so and tried it. >> >> { USB_DEVICE(VENDOR_TOPSEED, 0x0008) }, >> >> Still no joy! Arghhhh... >> >> The dev entry for the transmitter socket is not getting created. > > The transmit side uses the same device as receive, it doesn't create a > separate one. > > And for further clarification, the device entry isn't a socket, its an > lirc device. The socket is /var/run/lirc/lircd, created by the lirc > daemon, not by the driver. > >> I think this may be the main issue: >> >> could not get file information for /dev/lirc1 >> Jan 17 09:00:46 htpc lircd-0.8.6[9420]: default_init(): No such file >> or directory >> Jan 17 09:00:46 htpc lircd-0.8.6[9420]: Failed to initialize hardware >> >> If I mknod the device, it still does not work though. > > Yeah, don't do that, you're doing it wrong. > >> Always get irsend: hardware does not support sending > > ...because you're trying to transmit via a non-existent device. Try > using /dev/lirc0. Don't run a second lircd, one instance will handle > everything. OK, that I understand. The init script for ubuntu automagically creates the second listener socket on /dev/lircd1 just because I have a transmitter defined in my hardware.conf. REMOTE="Windows Media Center Transceivers/Remotes (all)" TRANSMITTER="Microsoft Windows Media Center V2 (usb) : Direct TV Receiver" REMOTE_MODULES="lirc_dev lirc_mceusb" REMOTE_DRIVER="" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" REMOTE_LIRCD_CONF="mceusb/lircd.conf.mceusb" REMOTE_LIRCD_ARGS="" TRANSMITTER_MODULES="lirc_dev lirc_mceusb" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/lirc0" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="directtv/H23.conf" TRANSMITTER_LIRCD_ARGS="" START_LIRCD="true" START_LIRCMD="" LOAD_MODULES="true" LIRCMD_CONF="" FORCE_NONINTERACTIVE_RECONFIGURATION="false" (I just changed the TRANSMITTER_DEVICE to lirc0 from lircd1) After this, restarting gives me this: 16560 ? Ss 0:00 /usr/sbin/lircd --output=/var/run/lirc/lircd --device=/dev/lirc0 --listen 16567 ? Ss 0:00 /usr/sbin/lircd --output=/var/run/lirc/lircd1 --device=/dev/lirc0 --connect=localhost 8765 --pidfile=/var/run/lirc/lircd1.pid Does these command line args look right? I appreciate the help - I've been pulling my head out.. irsend -d /dev/lircd SEND_ONCE directv info And in the logs: Jan 17 10:20:33 htpc lircd-0.8.6[16560]: accepted new client on /var/run/lirc/lircd Jan 17 10:20:33 htpc lircd-0.8.6[16560]: removed client Looks right to me.. irw /dev/lircd 0000000000000019 00 info directv So I can *hopefully* safely say my remotes are setup correctly for directv (It produces the right buttons).. Thanks! -Greg |
From: Jarod W. <ja...@wi...> - 2010-01-17 16:55:05
|
On Sun, Jan 17, 2010 at 11:23 AM, Greg Oliver <oli...@gm...> wrote: ... >>> could not get file information for /dev/lirc1 >>> Jan 17 09:00:46 htpc lircd-0.8.6[9420]: default_init(): No such file >>> or directory >>> Jan 17 09:00:46 htpc lircd-0.8.6[9420]: Failed to initialize hardware >>> >>> If I mknod the device, it still does not work though. >> >> Yeah, don't do that, you're doing it wrong. >> >>> Always get irsend: hardware does not support sending >> >> ...because you're trying to transmit via a non-existent device. Try >> using /dev/lirc0. Don't run a second lircd, one instance will handle >> everything. > > OK, that I understand. The init script for ubuntu automagically > creates the second listener socket on /dev/lircd1 just because I have > a transmitter defined in my hardware.conf. Oh, right, yeah. Its Ubuntu being "helpful". That's for the case where you have two different devices, it doesn't actually apply here. > REMOTE="Windows Media Center Transceivers/Remotes (all)" > TRANSMITTER="Microsoft Windows Media Center V2 (usb) : Direct TV Receiver" > REMOTE_MODULES="lirc_dev lirc_mceusb" > REMOTE_DRIVER="" > REMOTE_DEVICE="/dev/lirc0" > REMOTE_SOCKET="" > REMOTE_LIRCD_CONF="mceusb/lircd.conf.mceusb" > REMOTE_LIRCD_ARGS="" > TRANSMITTER_MODULES="lirc_dev lirc_mceusb" > TRANSMITTER_DRIVER="" > TRANSMITTER_DEVICE="/dev/lirc0" > TRANSMITTER_SOCKET="" > TRANSMITTER_LIRCD_CONF="directtv/H23.conf" > TRANSMITTER_LIRCD_ARGS="" > START_LIRCD="true" > START_LIRCMD="" > LOAD_MODULES="true" > LIRCMD_CONF="" > FORCE_NONINTERACTIVE_RECONFIGURATION="false" > > (I just changed the TRANSMITTER_DEVICE to lirc0 from lircd1) > > After this, restarting gives me this: > 16560 ? Ss 0:00 /usr/sbin/lircd > --output=/var/run/lirc/lircd --device=/dev/lirc0 --listen > 16567 ? Ss 0:00 /usr/sbin/lircd > --output=/var/run/lirc/lircd1 --device=/dev/lirc0 --connect=localhost > 8765 --pidfile=/var/run/lirc/lircd1.pid > > Does these command line args look right? Not quite. There's no reason to run a second lircd. Just run a single lircd with the remote conf files merged together, and everything should work. > I appreciate the help - I've been pulling my head out.. > > irsend -d /dev/lircd SEND_ONCE directv info > > And in the logs: > Jan 17 10:20:33 htpc lircd-0.8.6[16560]: accepted new client on > /var/run/lirc/lircd > Jan 17 10:20:33 htpc lircd-0.8.6[16560]: removed client > > Looks right to me.. > > irw /dev/lircd > 0000000000000019 00 info directv > > So I can *hopefully* safely say my remotes are setup correctly for > directv (It produces the right buttons).. > > Thanks! I suspect things may all work as you have them set up right now, but again, that second lircd instance is completely useless here. All its doing right now is opening another config file, but the single lircd instance can just open both (or a single file with the two configs merged together). -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-01-17 17:24:55
|
On Sun, Jan 17, 2010 at 10:54 AM, Jarod Wilson <ja...@wi...> wrote: > On Sun, Jan 17, 2010 at 11:23 AM, Greg Oliver <oli...@gm...> wrote: > ... >> OK, that I understand. The init script for ubuntu automagically >> creates the second listener socket on /dev/lircd1 just because I have >> a transmitter defined in my hardware.conf. > > Oh, right, yeah. Its Ubuntu being "helpful". That's for the case where > you have two different devices, it doesn't actually apply here. OK, I either have something really basic missing, or bad hardware. I have yet to get the LEDs to blink while trying to send with irsend, and everything I read says it will blink. I no longer have anything defined for the transmitter sections of my hardware.conf and both of my remote definitions are in a single file and called from there as well as lircd.conf. My running command is: /usr/sbin/lircd --output=/var/run/lirc/lircd --device=/dev/lirc0 It is still working as a receiver just fine. irsend does not error, but does not blink either. Is there something simple I am missing to tell it to transmit...? Is there anything simple I can try to test the hardware? [57980.937628] lirc_dev: IR Remote Control driver registered, major 61 [57980.947416] lirc_mceusb: Windows Media Center Edition USB IR Transceiver driver for LIRC 1.90 [57980.947429] lirc_mceusb: Daniel Melander <li...@ra...>, Martin Blatter <mar...@ya...>, Dan Conti <dc...@ac...> [57981.120054] usb 2-1: reset full speed USB device using ohci_hcd and address 2 [57981.340409] lirc_dev: lirc_register_driver: sample_rate: 0 [57981.348084] lirc_mceusb[2]: Topseed Technology Corp. eHome Infrared Transceiver on usb2:2 [57981.348245] usbcore: registered new interface driver lirc_mceusb Thanks, Greg > Not quite. There's no reason to run a second lircd. Just run a single > lircd with the remote conf files merged together, and everything > should work. > > > I suspect things may all work as you have them set up right now, but > again, that second lircd instance is completely useless here. All its > doing right now is opening another config file, but the single lircd > instance can just open both (or a single file with the two configs > merged together). > > > -- > Jarod Wilson > ja...@wi... > |
From: Jarod W. <ja...@wi...> - 2010-01-17 19:47:09
|
On Sun, Jan 17, 2010 at 12:24 PM, Greg Oliver <oli...@gm...> wrote: > On Sun, Jan 17, 2010 at 10:54 AM, Jarod Wilson <ja...@wi...> wrote: >> On Sun, Jan 17, 2010 at 11:23 AM, Greg Oliver <oli...@gm...> wrote: >> ... >>> OK, that I understand. The init script for ubuntu automagically >>> creates the second listener socket on /dev/lircd1 just because I have >>> a transmitter defined in my hardware.conf. >> >> Oh, right, yeah. Its Ubuntu being "helpful". That's for the case where >> you have two different devices, it doesn't actually apply here. > > OK, I either have something really basic missing, or bad hardware. I > have yet to get the LEDs to blink while trying to send with irsend, > and everything I read says it will blink. > > I no longer have anything defined for the transmitter sections of my > hardware.conf and both of my remote definitions are in a single file > and called from there as well as lircd.conf. > > My running command is: > > /usr/sbin/lircd --output=/var/run/lirc/lircd --device=/dev/lirc0 Good, looks much better. > It is still working as a receiver just fine. irsend does not error, > but does not blink either. Is there something simple I am missing to > tell it to transmit...? I don't think so. > Is there anything simple I can try to test the hardware? Double-check that stuff is actually coming out the emitter by looking at it through a webcam, phone cam, or other camera. I'd also try the other transmit port. Generally, flipping that transmit mask bit, one way or the other works just fine. Not sure what else to look at offhand... -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-01-17 21:20:40
|
On Sun, Jan 17, 2010 at 1:46 PM, Jarod Wilson <ja...@wi...> wrote: > On Sun, Jan 17, 2010 at 12:24 PM, Greg Oliver <oli...@gm...> wrote: >> On Sun, Jan 17, 2010 at 10:54 AM, Jarod Wilson <ja...@wi...> wrote: >>> On Sun, Jan 17, 2010 at 11:23 AM, Greg Oliver <oli...@gm...> wrote: >>> ... >>>> OK, that I understand. The init script for ubuntu automagically >>>> creates the second listener socket on /dev/lircd1 just because I have >>>> a transmitter defined in my hardware.conf. >>> >>> Oh, right, yeah. Its Ubuntu being "helpful". That's for the case where >>> you have two different devices, it doesn't actually apply here. >> >> OK, I either have something really basic missing, or bad hardware. I >> have yet to get the LEDs to blink while trying to send with irsend, >> and everything I read says it will blink. >> >> I no longer have anything defined for the transmitter sections of my >> hardware.conf and both of my remote definitions are in a single file >> and called from there as well as lircd.conf. >> >> My running command is: >> >> /usr/sbin/lircd --output=/var/run/lirc/lircd --device=/dev/lirc0 > > Good, looks much better. > >> It is still working as a receiver just fine. irsend does not error, >> but does not blink either. Is there something simple I am missing to >> tell it to transmit...? > > I don't think so. > >> Is there anything simple I can try to test the hardware? > > Double-check that stuff is actually coming out the emitter by looking > at it through a webcam, phone cam, or other camera. I'd also try the > other transmit port. Generally, flipping that transmit mask bit, one > way or the other works just fine. Not sure what else to look at > offhand... Thanks for all of the help, but I feel I have hit a brick wall - ie. hardware failure... The device blinks on receiving IR, so I just affixed the blaster to the receiver.. If it was blasting, the receiver would have blinked.. I searched high and low for an easy (even windows based) way to test. It seems that Vista64 (what my alptop came with), does not blast either.. Makes it hard to test :) If anyone knows of an easy piece of software (I have vista64, and xppro in a vm available - and of course native linux) to test it out.. Otherwise, I guess I will send it back.. The HDPVR blasted nicely from windows unfortunately.. I wish there was a hauppauge IR blaster program for mce remotes.. It was a 2 minute check! Thanks again for the help. I'll post back with a solution, or if I just return it... I got MCE compatible because everyone said "it just works"... Is there a blaster that's easy to come by (has to be USB - no serial ports here) other than MCE that "just works".. Seems the majority of people use the on-card stuff, but I only have the hdpvr and hdhomeruns.. I would like to use the hdpvr blaster, but if it locks it up, that would be bad.. Thanks again, Greg > -- > Jarod Wilson > ja...@wi... > |
From: Jarod W. <ja...@wi...> - 2010-01-18 02:33:17
|
On Sun, Jan 17, 2010 at 4:20 PM, Greg Oliver <oli...@gm...> wrote: ... >> Double-check that stuff is actually coming out the emitter by looking >> at it through a webcam, phone cam, or other camera. I'd also try the >> other transmit port. Generally, flipping that transmit mask bit, one >> way or the other works just fine. Not sure what else to look at >> offhand... > > Thanks for all of the help, but I feel I have hit a brick wall - ie. > hardware failure... The device blinks on receiving IR, so I just > affixed the blaster to the receiver.. If it was blasting, the > receiver would have blinked.. > > I searched high and low for an easy (even windows based) way to test. > It seems that Vista64 (what my alptop came with), does not blast > either.. Makes it hard to test :) > > If anyone knows of an easy piece of software (I have vista64, and > xppro in a vm available - and of course native linux) to test it out.. > Otherwise, I guess I will send it back.. > > The HDPVR blasted nicely from windows unfortunately.. I wish there > was a hauppauge IR blaster program for mce remotes.. It was a 2 > minute check! Yeah, unfortunately, I don't have a clue how to actually test blasting under Windows, I just know that its suggested as a sanity-check. :) > Thanks again for the help. I'll post back with a solution, or if I > just return it... I got MCE compatible because everyone said "it just > works"... > > Is there a blaster that's easy to come by (has to be USB - no serial > ports here) other than MCE that "just works".. Seems the majority of > people use the on-card stuff, but I only have the hdpvr and > hdhomeruns.. The mce stuff usually *does* Just Work. I have 3 mce transceivers that all work perfectly. It seems you've just been unlucky here. :\ > I would like to use the hdpvr blaster, but if it locks > it up, that would be bad.. Yeah, its likely to lock up (the hdpvr, not the computer its attached to, mind you). Digging into that is on my TODO list, but so are sooooo many other things... -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-01-21 23:16:18
|
On Sun, Jan 17, 2010 at 7:31 PM, Jarod Wilson <ja...@wi...> wrote: > On Sun, Jan 17, 2010 at 4:20 PM, Greg Oliver <oli...@gm...> wrote: > ... >>> Double-check that stuff is actually coming out the emitter by looking >>> at it through a webcam, phone cam, or other camera. I'd also try the >>> other transmit port. Generally, flipping that transmit mask bit, one >>> way or the other works just fine. Not sure what else to look at >>> offhand... I hate to re-hash this, but my replacement came in today with the same results... Arrrgh.. I've once again tried with the device masked and not in the source, and setting transmitters to 1 and 2 and on both physical ports. Does anything stand out from this output? [ 2255.840393] lirc_mceusb: Windows Media Center Edition USB IR Transceiver driver for LIRC 1.90 [ 2255.840404] lirc_mceusb: Daniel Melander <li...@ra...>, Martin Blatter <mar...@ya...>, Dan Conti <dc...@ac...> [ 2255.840413] lirc_mceusb: debug mode enabled [ 2255.840469] lirc_mceusb: mceusb_dev_probe called [ 2256.011306] usb 2-1: reset full speed USB device using ohci_hcd and address 2 [ 2256.230889] lirc_mceusb: acceptable outbound endpoint found [ 2256.230898] lirc_mceusb: acceptable inbound endpoint found [ 2256.230910] lirc_dev: lirc_register_driver: sample_rate: 0 [ 2256.238176] lirc_mceusb[2]: Topseed Technology Corp. eHome Infrared Transceiver on usb2:2 [ 2256.238195] lirc_mceusb[2]: receive request called (size=0x20) [ 2256.238218] lirc_mceusb[2]: receive request complete (res=0) [ 2256.238228] lirc_mceusb[2]: receive request called (size=0x20) [ 2256.238239] lirc_mceusb[2]: receive request complete (res=0) [ 2256.238248] lirc_mceusb[2]: receive request called (size=0x5) [ 2256.238261] lirc_mceusb[2]: receive request complete (res=0) [ 2256.238271] lirc_mceusb[2]: receive request called (size=0x20) [ 2256.238282] lirc_mceusb[2]: receive request complete (res=0) [ 2256.238291] lirc_mceusb[2]: receive request called (size=0x2) [ 2256.238301] lirc_mceusb[2]: receive request complete (res=0) [ 2256.238309] lirc_mceusb[2]: receive request called (size=0x20) [ 2256.238319] lirc_mceusb[2]: receive request complete (res=0) [ 2256.238415] usbcore: registered new interface driver lirc_mceusb [ 2256.239875] lirc_mceusb[2]: callback called (status=0 len=5) [ 2256.239891] lirc_mceusb[2]: data received 00 ff aa ff 0b (length=5) [ 2256.240879] lirc_mceusb[2]: callback called (status=0 len=2) [ 2256.240892] lirc_mceusb[2]: data received ff fe (length=2) [ 2256.240903] lirc_mceusb[2]: callback called (status=0 len=2) [ 2256.240912] lirc_mceusb[2]: data received ff 18 (length=2) [ 2257.164843] lirc_mceusb[2]: mceusb IR device opened [ 2280.102680] lirc_mceusb: SET_TRANSMITTERS mask=3 [ 2283.732675] lirc_mceusb[2]: SET_CARRIER requesting 38000 Hz [ 2283.732687] lirc_mceusb[2]: receive request called (size=0x4) [ 2283.732703] lirc_mceusb[2]: receive request complete (res=0) [ 2283.732726] lirc_mceusb[2]: receive request called (size=0x1c) [ 2283.732734] lirc_mceusb[2]: receive request complete (res=0) [ 2283.734031] lirc_mceusb[2]: callback called (status=0 len=4) [ 2283.734041] lirc_mceusb[2]: data received 9f 06 01 41 (length=4) [ 2283.735020] lirc_mceusb[2]: callback called (status=0 len=28) [ 2283.735037] lirc_mceusb[2]: data received 9f 08 06 84 f8 16 9a 16 84 8d 0b 8d 0b 84 99 0a 99 0b 84 8d 0b 8d 0b 83 8c 0b 8d 80 (length=28) Thanks, Greg |