From: Krister H. <kr...@ha...> - 2011-04-19 11:50:28
|
Thought I was replying to the lirc-list, sorry. Deleted hardware.conf but added LIRC_DRIVER="dev/input" and LIRC_DEVICE="/dev/input/irremote". Hope the below is that relevant boot output: [root@DESKTOP /]# dmesg | grep lirc [ 8.332730] lirc_dev: IR Remote Control driver registered, major 249 [ 8.349352] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0 [root@DESKTOP /]# dmesg | grep LIRC [ 8.349359] IR LIRC bridge handler initialized [root@DESKTOP /]# dmesg | grep cx88 [ 7.730279] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded [ 7.730311] cx8800 0000:05:05.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [ 7.730773] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.8 loaded [ 7.731818] cx88[0]: subsystem: 0070:9002, board: Hauppauge Nova-T DVB-T [card=18,autodetected], frontend(s): 1 [ 7.731821] cx88[0]: TV tuner type 4, Radio tuner type -1 [ 7.883390] cx88[0]: hauppauge eeprom: model=90003 [ 7.948568] input: cx88 IR (Hauppauge Nova-T DVB-T as /devices/pci0000:00/0000:00:1e.0/0000:05:05.0/rc/rc0/input4 [ 7.948596] rc0: cx88 IR (Hauppauge Nova-T DVB-T as /devices/pci0000:00/0000:00:1e.0/0000:05:05.0/rc/rc0 [ 7.948626] cx88[0]/0: found at 0000:05:05.0, rev: 5, irq: 19, latency: 32, mmio: 0xfa000000 [ 7.948674] cx88[0]/0: registered device video0 [v4l2] [ 7.948701] cx88[0]/0: registered device vbi0 [ 7.948755] cx88[0]/2: cx2388x 8802 Driver Manager [ 7.948769] cx88-mpeg driver manager 0000:05:05.2: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [ 7.948775] cx88[0]/2: found at 0000:05:05.2, rev: 5, irq: 19, latency: 32, mmio: 0xf9000000 [ 8.349352] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0 [ 8.492086] cx88/2: cx2388x dvb driver version 0.0.8 loaded [ 8.492089] cx88/2: registering cx8802 driver, type: dvb access: shared [ 8.492092] cx88[0]/2: subsystem: 0070:9002, board: Hauppauge Nova-T DVB-T [card=18] [ 8.492094] cx88[0]/2: cx2388x based DVB/ATSC card [ 8.492095] cx8802_alloc_frontends() allocating 1 frontend(s) [ 8.618036] DVB: registering new adapter (cx88[0]) [root@DESKTOP /]# lspci | grep Conexant 05:05.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 05:05.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) 05:05.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] (rev 05) Thanks, Krister -------------------------------------------------- From: "Jarod Wilson" <ja...@wi...> Sent: Monday, April 18, 2011 11:09 PM To: "Krister Hallergard" <kr...@ha...> Cc: "mailing list: lirc" <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On Apr 18, 2011, at 5:27 PM, Krister Hallergard wrote: > >> Thank you Jarod, I trust you. Got your message re hardware.conf (use >> /etc/sysconfig/lirc instead?), and have tried without it, but the >> situation does not change. Using Hauppauge Nova-T-PCI and their gray 45 >> button remote. > > Please keep the discussion on the mailing list. I do have an idea of > what might be going on there though, will need to check some code to > see if the theory pans out. Will also need lspci and relevant dmesg > output surrounding device bring-up after boot. > > >> -------------------------------------------------- >> From: "Jarod Wilson" <ja...@wi...> >> Sent: Monday, April 18, 2011 8:00 PM >> To: "Krister Hallergard" <kr...@ha...> >> Cc: <lir...@li...> >> Subject: Re: Lirc damon running but no output in Fedora 14 >> >>> On Apr 18, 2011, at 2:08 PM, Krister Hallergard wrote: >>> >>>> Thought the reason for LIRC was not working with F14 was that the >>>> kernel changes for lirc had not been properly implemented, but still >>>> cannot get it working with the latest >>>> kernel-2.6.35.12-88.fc14.i686.PAE. Using latest version >>>> lirc-0.9.0-1..fc14 (i686). >>> >>> Trust me, the lirc code in F14 is properly implemented... :) >>> >>> >>>> Checking lirc status (/etc/init.d/lirc status) gives "lircd (pid 1538) >>>> is running..." >>>> ls /dev/lirc* gives " lircd0" >>>> ls /var/run/lirc gives "lircd lircd.pid" >>>> >>>> Activating with "irexec -d" and irxevent -d" it should be working - but >>>> it isn't - so I tried this in a root terminal: >>>> Code: >>>> rm /var/run/lirc/lircd.pid >>>> /usr/sbin/lircd -H dev/input -d /dev/input/irremote -n >>>> >>>> And in another terminal: irw >>>> pressing buttons gives no output, despite the first terminal showing: >>>> Code: >>>> lircd-0.9.0[18223]: lircd(devinput) ready, using /var/run/lirc/lircd >>>> lircd-0.9.0[18223]: accepted new client on /var/run/lirc/lircd >>>> lircd-0.9.0[18223]: initializing '/dev/input/irremote' >>>> >>>> Everything else is that same as in F13 where LIRC works fine, including >>>> the KERNEL=="event*", ATTRS{vendor}=="0x14f1", >>>> SYMLINK+="input/irremote" added to /etc/udev/10local.rules and >>>> hardware.conf rather minimal: >>>> Code: >>>> LIRCD_ARGS="" >>>> LOAD_MODULES=true >>>> DRIVER="dev/input" >>>> DEVICE="/dev/input/irremote" >>>> MODULES="lirc_dev" >>>> LIRCD_CONF="" >>>> >>>> Any suggestions would be very much appreciated >>> >>> Uh. hardware.conf? That's a Debian-ism. Not an upstream lirc thing. It >>> has absolutely no meaning on a Fedora system. >>> >>> What IR hardware and what remote are you trying to use here? > > -- > Jarod Wilson > ja...@wi... > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1321 / Virus Database: 1500/3582 - Release Date: 04/18/11 > > |
From: Douglas C. <dcl...@op...> - 2011-04-19 13:19:26
|
Krister, This looks very similar to one of my systems, a Leadtek Winfast DTV1000-T. I think that there are one or two tables that you need to make the connection. One of the things that your grep leaves out is the "IR keymap" mine is "rc-winfast", as in: [ 14.727025] Registered IR keymap rc-winfast [ 14.727159] input: cx88 IR (WinFast DTV1000-T) as /devices/pci0000:00/0000:00:1e.0/0000:01:00.2/rc/rc1/input18 [ 14.727249] rc1: cx88 IR (WinFast DTV1000-T) as /devices/pci0000:00/0000:00:1e.0/0000:01:00.2/rc/rc1 without this, scancodes from the driver may not get mapped to keycodes on the input event. The other is the lirc conf file which is specified to lircd. You don't show one but mine is: # ps -ef | grep lircd ... /usr/sbin/lircd --driver=devinput --device=name=cx88 IR* --output=/var/run/lirc/lircd /etc/lirc/lircd.conf.devinput Use ir-keytable (yum install v4l-utils) to show your devices and config: # ir-keytable Found /sys/class/rc/rc1/ (/dev/input/event18) with: Driver cx88xx, table rc-winfast Supported protocols: Enabled protocols: Repeat delay = 500 ms, repeat period = 33 ms and to test keys (without lircd running), theses are the keys 1, 2, and 3: # ir-keytable -s rc1 -t Testing events. Please, press CTRL-C to abort. 1303218695.077572: event MSC: scancode = 05 1303218695.077581: event key down: KEY_1 (0x0002) 1303218695.077584: event sync 1303218695.079558: event key up: KEY_1 (0x0002) 1303218695.079563: event sync 1303218695.834592: event MSC: scancode = 06 1303218695.834601: event key down: KEY_2 (0x0003) 1303218695.834603: event sync 1303218695.835556: event key up: KEY_2 (0x0003) 1303218695.835560: event sync 1303218697.040591: event MSC: scancode = 07 1303218697.040602: event key down: KEY_3 (0x0004) 1303218697.040605: event sync 1303218697.041556: event key up: KEY_3 (0x0004) 1303218697.041560: event sync ^C or # evtest /dev/input/event18 ]# evtest /dev/input/event18 Input driver version is 1.0.0 Input device ID: bus 0x1 vendor 0x107d product 0x665f version 0x1 Input device name: "cx88 IR (WinFast DTV1000-T)" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 2 (1) Event code 3 (2) Event code 4 (3) ... Testing ... (interrupt to exit) Event: time 1303218565.586626, type 4 (Misc), code 4 (ScanCode), value 05 Event: time 1303218565.586635, type 1 (Key), code 2 (1), value 1 Event: time 1303218565.586638, -------------- Report Sync ------------ Event: time 1303218565.588558, type 1 (Key), code 2 (1), value 0 Event: time 1303218565.588564, -------------- Report Sync ------------ Event: time 1303218566.320644, type 4 (Misc), code 4 (ScanCode), value 06 Event: time 1303218566.320653, type 1 (Key), code 3 (2), value 1 Event: time 1303218566.320656, -------------- Report Sync ------------ Event: time 1303218566.322557, type 1 (Key), code 3 (2), value 0 Event: time 1303218566.322562, -------------- Report Sync ------------ Event: time 1303218567.148579, type 4 (Misc), code 4 (ScanCode), value 07 Event: time 1303218567.148589, type 1 (Key), code 4 (3), value 1 Event: time 1303218567.148591, -------------- Report Sync ------------ Event: time 1303218567.149585, type 1 (Key), code 4 (3), value 0 Event: time 1303218567.149588, -------------- Report Sync ------------ ^C the file lirc.conf.devinput contains mapping from the key codes to lirc codes, in part ... KEY_1 2 KEY_2 3 KEY_3 4 KEY_4 5 KEY_5 6 ... Then, with lircd running, you should see events from irw: # irw 0000000080010002 00 KEY_1 devinput 0000000080010003 00 KEY_2 devinput 0000000080010004 00 KEY_3 devinput Cheers, Douglas On 2011-04-19 21:50, Krister Hallergard wrote: > Thought I was replying to the lirc-list, sorry. Deleted hardware.conf but > added LIRC_DRIVER="dev/input" and LIRC_DEVICE="/dev/input/irremote". Hope > the below is that relevant boot output: > > [root@DESKTOP /]# dmesg | grep lirc > [ 8.332730] lirc_dev: IR Remote Control driver registered, major 249 > [ 8.349352] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at > minor = 0 > [root@DESKTOP /]# dmesg | grep LIRC > [ 8.349359] IR LIRC bridge handler initialized > > [root@DESKTOP /]# dmesg | grep cx88 > [ 7.730279] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded > [ 7.730311] cx8800 0000:05:05.0: PCI INT A -> GSI 19 (level, low) -> IRQ > 19 > [ 7.730773] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.8 loaded > [ 7.731818] cx88[0]: subsystem: 0070:9002, board: Hauppauge Nova-T DVB-T > [card=18,autodetected], frontend(s): 1 > [ 7.731821] cx88[0]: TV tuner type 4, Radio tuner type -1 > [ 7.883390] cx88[0]: hauppauge eeprom: model=90003 > [ 7.948568] input: cx88 IR (Hauppauge Nova-T DVB-T as > /devices/pci0000:00/0000:00:1e.0/0000:05:05.0/rc/rc0/input4 > [ 7.948596] rc0: cx88 IR (Hauppauge Nova-T DVB-T as > /devices/pci0000:00/0000:00:1e.0/0000:05:05.0/rc/rc0 > [ 7.948626] cx88[0]/0: found at 0000:05:05.0, rev: 5, irq: 19, latency: > 32, mmio: 0xfa000000 > [ 7.948674] cx88[0]/0: registered device video0 [v4l2] > [ 7.948701] cx88[0]/0: registered device vbi0 > [ 7.948755] cx88[0]/2: cx2388x 8802 Driver Manager > [ 7.948769] cx88-mpeg driver manager 0000:05:05.2: PCI INT A -> GSI 19 > (level, low) -> IRQ 19 > [ 7.948775] cx88[0]/2: found at 0000:05:05.2, rev: 5, irq: 19, latency: > 32, mmio: 0xf9000000 > [ 8.349352] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at > minor = 0 > [ 8.492086] cx88/2: cx2388x dvb driver version 0.0.8 loaded > [ 8.492089] cx88/2: registering cx8802 driver, type: dvb access: shared > [ 8.492092] cx88[0]/2: subsystem: 0070:9002, board: Hauppauge Nova-T > DVB-T [card=18] > [ 8.492094] cx88[0]/2: cx2388x based DVB/ATSC card > [ 8.492095] cx8802_alloc_frontends() allocating 1 frontend(s) > [ 8.618036] DVB: registering new adapter (cx88[0]) > > [root@DESKTOP /]# lspci | grep Conexant > 05:05.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 > PCI Video and Audio Decoder (rev 05) > 05:05.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI > Video and Audio Decoder [MPEG Port] (rev 05) > 05:05.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI > Video and Audio Decoder [IR Port] (rev 05) > > Thanks, Krister > -------------------------------------------------- > From: "Jarod Wilson"<ja...@wi...> > Sent: Monday, April 18, 2011 11:09 PM > To: "Krister Hallergard"<kr...@ha...> > Cc: "mailing list: lirc"<lir...@li...> > Subject: Re: Lirc damon running but no output in Fedora 14 > >> On Apr 18, 2011, at 5:27 PM, Krister Hallergard wrote: >> >>> Thank you Jarod, I trust you. Got your message re hardware.conf (use >>> /etc/sysconfig/lirc instead?), and have tried without it, but the >>> situation does not change. Using Hauppauge Nova-T-PCI and their gray 45 >>> button remote. >> Please keep the discussion on the mailing list. I do have an idea of >> what might be going on there though, will need to check some code to >> see if the theory pans out. Will also need lspci and relevant dmesg >> output surrounding device bring-up after boot. >> >> >>> -------------------------------------------------- >>> From: "Jarod Wilson"<ja...@wi...> >>> Sent: Monday, April 18, 2011 8:00 PM >>> To: "Krister Hallergard"<kr...@ha...> >>> Cc:<lir...@li...> >>> Subject: Re: Lirc damon running but no output in Fedora 14 >>> >>>> On Apr 18, 2011, at 2:08 PM, Krister Hallergard wrote: >>>> >>>>> Thought the reason for LIRC was not working with F14 was that the >>>>> kernel changes for lirc had not been properly implemented, but still >>>>> cannot get it working with the latest >>>>> kernel-2.6.35.12-88.fc14.i686.PAE. Using latest version >>>>> lirc-0.9.0-1..fc14 (i686). >>>> Trust me, the lirc code in F14 is properly implemented... :) >>>> >>>> >>>>> Checking lirc status (/etc/init.d/lirc status) gives "lircd (pid 1538) >>>>> is running..." >>>>> ls /dev/lirc* gives " lircd0" >>>>> ls /var/run/lirc gives "lircd lircd.pid" >>>>> >>>>> Activating with "irexec -d" and irxevent -d" it should be working - but >>>>> it isn't - so I tried this in a root terminal: >>>>> Code: >>>>> rm /var/run/lirc/lircd.pid >>>>> /usr/sbin/lircd -H dev/input -d /dev/input/irremote -n >>>>> >>>>> And in another terminal: irw >>>>> pressing buttons gives no output, despite the first terminal showing: >>>>> Code: >>>>> lircd-0.9.0[18223]: lircd(devinput) ready, using /var/run/lirc/lircd >>>>> lircd-0.9.0[18223]: accepted new client on /var/run/lirc/lircd >>>>> lircd-0.9.0[18223]: initializing '/dev/input/irremote' >>>>> >>>>> Everything else is that same as in F13 where LIRC works fine, including >>>>> the KERNEL=="event*", ATTRS{vendor}=="0x14f1", >>>>> SYMLINK+="input/irremote" added to /etc/udev/10local.rules and >>>>> hardware.conf rather minimal: >>>>> Code: >>>>> LIRCD_ARGS="" >>>>> LOAD_MODULES=true >>>>> DRIVER="dev/input" >>>>> DEVICE="/dev/input/irremote" >>>>> MODULES="lirc_dev" >>>>> LIRCD_CONF="" >>>>> >>>>> Any suggestions would be very much appreciated >>>> Uh. hardware.conf? That's a Debian-ism. Not an upstream lirc thing. It >>>> has absolutely no meaning on a Fedora system. >>>> >>>> What IR hardware and what remote are you trying to use here? >> -- >> Jarod Wilson >> ja...@wi... >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1321 / Virus Database: 1500/3582 - Release Date: 04/18/11 >> >> > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev |
From: Jarod W. <ja...@wi...> - 2011-04-19 14:17:32
|
On Apr 19, 2011, at 9:18 AM, Douglas Clowes wrote: > Krister, > > This looks very similar to one of my systems, a Leadtek Winfast > DTV1000-T. I think that there are one or two tables that you need to > make the connection. > > One of the things that your grep leaves out is the "IR keymap" mine is > "rc-winfast", as in: > [ 14.727025] Registered IR keymap rc-winfast > [ 14.727159] input: cx88 IR (WinFast DTV1000-T) as > /devices/pci0000:00/0000:00:1e.0/0000:01:00.2/rc/rc1/input18 > [ 14.727249] rc1: cx88 IR (WinFast DTV1000-T) as > /devices/pci0000:00/0000:00:1e.0/0000:01:00.2/rc/rc1 > > without this, scancodes from the driver may not get mapped to keycodes > on the input event. > > The other is the lirc conf file which is specified to lircd. You don't > show one but mine is: > > # ps -ef | grep lircd > ... /usr/sbin/lircd --driver=devinput --device=name=cx88 IR* > --output=/var/run/lirc/lircd /etc/lirc/lircd.conf.devinput > > Use ir-keytable (yum install v4l-utils) to show your devices and config: > # ir-keytable > Found /sys/class/rc/rc1/ (/dev/input/event18) with: > Driver cx88xx, table rc-winfast > Supported protocols: > Enabled protocols: > Repeat delay = 500 ms, repeat period = 33 ms > and to test keys (without lircd running), theses are the keys 1, 2, and 3: > # ir-keytable -s rc1 -t > Testing events. Please, press CTRL-C to abort. > 1303218695.077572: event MSC: scancode = 05 > 1303218695.077581: event key down: KEY_1 (0x0002) > 1303218695.077584: event sync > 1303218695.079558: event key up: KEY_1 (0x0002) > 1303218695.079563: event sync > 1303218695.834592: event MSC: scancode = 06 > 1303218695.834601: event key down: KEY_2 (0x0003) > 1303218695.834603: event sync > 1303218695.835556: event key up: KEY_2 (0x0003) > 1303218695.835560: event sync > 1303218697.040591: event MSC: scancode = 07 > 1303218697.040602: event key down: KEY_3 (0x0004) > 1303218697.040605: event sync > 1303218697.041556: event key up: KEY_3 (0x0004) > 1303218697.041560: event sync Okay, double-checked some code... Definitely need to the output of ir-keytable (with no args) to see what keytable is assigned. There's a bit of an issue with multiple Hauppauge keytables and a mix of raw IR decoders and scancode-based decoders in Hauppauge hardware, which will be mostly sorted out in 2.6.39.... Running ir-keytable in test mode (-t) and pressing some buttons would also be useful info to see. > On 2011-04-19 21:50, Krister Hallergard wrote: >> Thought I was replying to the lirc-list, sorry. Deleted hardware.conf but >> added LIRC_DRIVER="dev/input" and LIRC_DEVICE="/dev/input/irremote". Hope >> the below is that relevant boot output: >> >> [root@DESKTOP /]# dmesg | grep lirc >> [ 8.332730] lirc_dev: IR Remote Control driver registered, major 249 >> [ 8.349352] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at >> minor = 0 >> [root@DESKTOP /]# dmesg | grep LIRC >> [ 8.349359] IR LIRC bridge handler initialized >> >> [root@DESKTOP /]# dmesg | grep cx88 >> [ 7.730279] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded >> [ 7.730311] cx8800 0000:05:05.0: PCI INT A -> GSI 19 (level, low) -> IRQ >> 19 >> [ 7.730773] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.8 loaded >> [ 7.731818] cx88[0]: subsystem: 0070:9002, board: Hauppauge Nova-T DVB-T >> [card=18,autodetected], frontend(s): 1 >> [ 7.731821] cx88[0]: TV tuner type 4, Radio tuner type -1 >> [ 7.883390] cx88[0]: hauppauge eeprom: model=90003 >> [ 7.948568] input: cx88 IR (Hauppauge Nova-T DVB-T as >> /devices/pci0000:00/0000:00:1e.0/0000:05:05.0/rc/rc0/input4 >> [ 7.948596] rc0: cx88 IR (Hauppauge Nova-T DVB-T as >> /devices/pci0000:00/0000:00:1e.0/0000:05:05.0/rc/rc0 >> [ 7.948626] cx88[0]/0: found at 0000:05:05.0, rev: 5, irq: 19, latency: >> 32, mmio: 0xfa000000 >> [ 7.948674] cx88[0]/0: registered device video0 [v4l2] >> [ 7.948701] cx88[0]/0: registered device vbi0 >> [ 7.948755] cx88[0]/2: cx2388x 8802 Driver Manager >> [ 7.948769] cx88-mpeg driver manager 0000:05:05.2: PCI INT A -> GSI 19 >> (level, low) -> IRQ 19 >> [ 7.948775] cx88[0]/2: found at 0000:05:05.2, rev: 5, irq: 19, latency: >> 32, mmio: 0xf9000000 >> [ 8.349352] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at >> minor = 0 >> [ 8.492086] cx88/2: cx2388x dvb driver version 0.0.8 loaded >> [ 8.492089] cx88/2: registering cx8802 driver, type: dvb access: shared >> [ 8.492092] cx88[0]/2: subsystem: 0070:9002, board: Hauppauge Nova-T >> DVB-T [card=18] >> [ 8.492094] cx88[0]/2: cx2388x based DVB/ATSC card >> [ 8.492095] cx8802_alloc_frontends() allocating 1 frontend(s) >> [ 8.618036] DVB: registering new adapter (cx88[0]) >> >> [root@DESKTOP /]# lspci | grep Conexant >> 05:05.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 >> PCI Video and Audio Decoder (rev 05) >> 05:05.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI >> Video and Audio Decoder [MPEG Port] (rev 05) >> 05:05.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI >> Video and Audio Decoder [IR Port] (rev 05) >> >> Thanks, Krister >> -------------------------------------------------- >> From: "Jarod Wilson"<ja...@wi...> >> Sent: Monday, April 18, 2011 11:09 PM >> To: "Krister Hallergard"<kr...@ha...> >> Cc: "mailing list: lirc"<lir...@li...> >> Subject: Re: Lirc damon running but no output in Fedora 14 >> >>> On Apr 18, 2011, at 5:27 PM, Krister Hallergard wrote: >>> >>>> Thank you Jarod, I trust you. Got your message re hardware.conf (use >>>> /etc/sysconfig/lirc instead?), and have tried without it, but the >>>> situation does not change. Using Hauppauge Nova-T-PCI and their gray 45 >>>> button remote. >>> Please keep the discussion on the mailing list. I do have an idea of >>> what might be going on there though, will need to check some code to >>> see if the theory pans out. Will also need lspci and relevant dmesg >>> output surrounding device bring-up after boot. >>> >>> >>>> -------------------------------------------------- >>>> From: "Jarod Wilson"<ja...@wi...> >>>> Sent: Monday, April 18, 2011 8:00 PM >>>> To: "Krister Hallergard"<kr...@ha...> >>>> Cc:<lir...@li...> >>>> Subject: Re: Lirc damon running but no output in Fedora 14 >>>> >>>>> On Apr 18, 2011, at 2:08 PM, Krister Hallergard wrote: >>>>> >>>>>> Thought the reason for LIRC was not working with F14 was that the >>>>>> kernel changes for lirc had not been properly implemented, but still >>>>>> cannot get it working with the latest >>>>>> kernel-2.6.35.12-88.fc14.i686.PAE. Using latest version >>>>>> lirc-0.9.0-1..fc14 (i686). >>>>> Trust me, the lirc code in F14 is properly implemented... :) >>>>> >>>>> >>>>>> Checking lirc status (/etc/init.d/lirc status) gives "lircd (pid 1538) >>>>>> is running..." >>>>>> ls /dev/lirc* gives " lircd0" >>>>>> ls /var/run/lirc gives "lircd lircd.pid" >>>>>> >>>>>> Activating with "irexec -d" and irxevent -d" it should be working - but >>>>>> it isn't - so I tried this in a root terminal: >>>>>> Code: >>>>>> rm /var/run/lirc/lircd.pid >>>>>> /usr/sbin/lircd -H dev/input -d /dev/input/irremote -n >>>>>> >>>>>> And in another terminal: irw >>>>>> pressing buttons gives no output, despite the first terminal showing: >>>>>> Code: >>>>>> lircd-0.9.0[18223]: lircd(devinput) ready, using /var/run/lirc/lircd >>>>>> lircd-0.9.0[18223]: accepted new client on /var/run/lirc/lircd >>>>>> lircd-0.9.0[18223]: initializing '/dev/input/irremote' >>>>>> >>>>>> Everything else is that same as in F13 where LIRC works fine, including >>>>>> the KERNEL=="event*", ATTRS{vendor}=="0x14f1", >>>>>> SYMLINK+="input/irremote" added to /etc/udev/10local.rules and >>>>>> hardware.conf rather minimal: >>>>>> Code: >>>>>> LIRCD_ARGS="" >>>>>> LOAD_MODULES=true >>>>>> DRIVER="dev/input" >>>>>> DEVICE="/dev/input/irremote" >>>>>> MODULES="lirc_dev" >>>>>> LIRCD_CONF="" >>>>>> >>>>>> Any suggestions would be very much appreciated >>>>> Uh. hardware.conf? That's a Debian-ism. Not an upstream lirc thing. It >>>>> has absolutely no meaning on a Fedora system. >>>>> >>>>> What IR hardware and what remote are you trying to use here? >>> -- >>> Jarod Wilson >>> ja...@wi... >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 10.0.1321 / Virus Database: 1500/3582 - Release Date: 04/18/11 >>> >>> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- Jarod Wilson ja...@wi... |
From: Krister H. <kr...@ha...> - 2011-04-19 16:44:47
|
Thanks Douglas and Jarod. Yes this seems to be my problem. [root@DESKTOP /]# dmesg | grep keymap [ 6.916127] Registered IR keymap rc-hauppauge-new [root@DESKTOP /]# ps -ef | grep lircd root 1527 1 0 17:00 ? 00:00:00 /usr/sbin/lircd --driver=dev/input --device=/dev/input/irremote root 2772 2724 0 17:03 pts/3 00:00:00 grep --color=auto lircd No output - my /etc/lirc/lirc.conf is not recognized Have tried renaming is lirc.conf.devinput - no change. Have tried to copy over the file /usr/share/lirc-remotes/devinput/lirc.conf.devinput -no change. Should I generate my own lirc.conf.devinput? [root@DESKTOP mnt]# ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event5) with: Driver cx88xx, table rc-hauppauge-new Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: LIRC Repeat delay = 500 ms, repeat period = 33 ms There is not output with ir-keytable -t or ir-keytable -s rc0 -t [root@DESKTOP /]# evtest /dev/input/event5 Input driver version is 1.0.0 Input device ID: bus 0x1 vendor 0x70 product 0x9002 version 0x1 Input device name: "cx88 IR (Hauppauge Nova-T DVB-T" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 2 (1) Event code 3 (2) Event code 4 (3) Event code 5 (4) Event code 6 (5) Event code 7 (6) Event code 8 (7) Event code 9 (8) Event code 10 (9) Event code 11 (0) Event code 28 (Enter) Event code 103 (Up) Event code 105 (Left) Event code 106 (Right) etc, etc Event code 400 (Yellow) Event code 401 (Blue) Event code 402 (ChannelUp) Event code 403 (ChannelDown) Event code 412 (Previous) Event type 4 (Misc) Event code 4 (ScanCode) Event type 20 (Repeat) Testing ... (interrupt to exit) *********************************************** This device is grabbed by another process. No events are available to evtest while the other grab is active. In most cases, this is caused by an X driver, try VT-switching and re-run evtest again. *********************************************** Wonder what the above means?? (in F13 there was no /dev/lirc0 - could this have something to do with it_). There is not output from evtest /dev/input/event5 Cheers, Krister -------------------------------------------------- From: "Jarod Wilson" <ja...@wi...> Sent: Tuesday, April 19, 2011 3:17 PM To: <dcl...@op...> Cc: "Krister Hallergard" <kr...@ha...>; <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On Apr 19, 2011, at 9:18 AM, Douglas Clowes wrote: > >> Krister, >> >> This looks very similar to one of my systems, a Leadtek Winfast >> DTV1000-T. I think that there are one or two tables that you need to >> make the connection. >> >> One of the things that your grep leaves out is the "IR keymap" mine is >> "rc-winfast", as in: >> [ 14.727025] Registered IR keymap rc-winfast >> [ 14.727159] input: cx88 IR (WinFast DTV1000-T) as >> /devices/pci0000:00/0000:00:1e.0/0000:01:00.2/rc/rc1/input18 >> [ 14.727249] rc1: cx88 IR (WinFast DTV1000-T) as >> /devices/pci0000:00/0000:00:1e.0/0000:01:00.2/rc/rc1 >> >> without this, scancodes from the driver may not get mapped to keycodes >> on the input event. >> >> The other is the lirc conf file which is specified to lircd. You don't >> show one but mine is: >> >> # ps -ef | grep lircd >> ... /usr/sbin/lircd --driver=devinput --device=name=cx88 IR* >> --output=/var/run/lirc/lircd /etc/lirc/lircd.conf.devinput >> >> Use ir-keytable (yum install v4l-utils) to show your devices and config: >> # ir-keytable >> Found /sys/class/rc/rc1/ (/dev/input/event18) with: >> Driver cx88xx, table rc-winfast >> Supported protocols: >> Enabled protocols: >> Repeat delay = 500 ms, repeat period = 33 ms >> and to test keys (without lircd running), theses are the keys 1, 2, and >> 3: >> # ir-keytable -s rc1 -t >> Testing events. Please, press CTRL-C to abort. >> 1303218695.077572: event MSC: scancode = 05 >> 1303218695.077581: event key down: KEY_1 (0x0002) >> 1303218695.077584: event sync >> 1303218695.079558: event key up: KEY_1 (0x0002) >> 1303218695.079563: event sync >> 1303218695.834592: event MSC: scancode = 06 >> 1303218695.834601: event key down: KEY_2 (0x0003) >> 1303218695.834603: event sync >> 1303218695.835556: event key up: KEY_2 (0x0003) >> 1303218695.835560: event sync >> 1303218697.040591: event MSC: scancode = 07 >> 1303218697.040602: event key down: KEY_3 (0x0004) >> 1303218697.040605: event sync >> 1303218697.041556: event key up: KEY_3 (0x0004) >> 1303218697.041560: event sync > > Okay, double-checked some code... Definitely need to the output of > ir-keytable (with no args) to see what keytable is assigned. There's > a bit of an issue with multiple Hauppauge keytables and a mix of > raw IR decoders and scancode-based decoders in Hauppauge hardware, > which will be mostly sorted out in 2.6.39.... Running ir-keytable > in test mode (-t) and pressing some buttons would also be useful info > to see. > > >> On 2011-04-19 21:50, Krister Hallergard wrote: >>> Thought I was replying to the lirc-list, sorry. Deleted hardware.conf >>> but >>> added LIRC_DRIVER="dev/input" and LIRC_DEVICE="/dev/input/irremote". >>> Hope >>> the below is that relevant boot output: >>> >>> [root@DESKTOP /]# dmesg | grep lirc >>> [ 8.332730] lirc_dev: IR Remote Control driver registered, major 249 >>> [ 8.349352] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) >>> registered at >>> minor = 0 >>> [root@DESKTOP /]# dmesg | grep LIRC >>> [ 8.349359] IR LIRC bridge handler initialized >>> >>> [root@DESKTOP /]# dmesg | grep cx88 >>> [ 7.730279] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded >>> [ 7.730311] cx8800 0000:05:05.0: PCI INT A -> GSI 19 (level, low) -> >>> IRQ >>> 19 >>> [ 7.730773] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.8 >>> loaded >>> [ 7.731818] cx88[0]: subsystem: 0070:9002, board: Hauppauge Nova-T >>> DVB-T >>> [card=18,autodetected], frontend(s): 1 >>> [ 7.731821] cx88[0]: TV tuner type 4, Radio tuner type -1 >>> [ 7.883390] cx88[0]: hauppauge eeprom: model=90003 >>> [ 7.948568] input: cx88 IR (Hauppauge Nova-T DVB-T as >>> /devices/pci0000:00/0000:00:1e.0/0000:05:05.0/rc/rc0/input4 >>> [ 7.948596] rc0: cx88 IR (Hauppauge Nova-T DVB-T as >>> /devices/pci0000:00/0000:00:1e.0/0000:05:05.0/rc/rc0 >>> [ 7.948626] cx88[0]/0: found at 0000:05:05.0, rev: 5, irq: 19, >>> latency: >>> 32, mmio: 0xfa000000 >>> [ 7.948674] cx88[0]/0: registered device video0 [v4l2] >>> [ 7.948701] cx88[0]/0: registered device vbi0 >>> [ 7.948755] cx88[0]/2: cx2388x 8802 Driver Manager >>> [ 7.948769] cx88-mpeg driver manager 0000:05:05.2: PCI INT A -> GSI >>> 19 >>> (level, low) -> IRQ 19 >>> [ 7.948775] cx88[0]/2: found at 0000:05:05.2, rev: 5, irq: 19, >>> latency: >>> 32, mmio: 0xf9000000 >>> [ 8.349352] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) >>> registered at >>> minor = 0 >>> [ 8.492086] cx88/2: cx2388x dvb driver version 0.0.8 loaded >>> [ 8.492089] cx88/2: registering cx8802 driver, type: dvb access: >>> shared >>> [ 8.492092] cx88[0]/2: subsystem: 0070:9002, board: Hauppauge Nova-T >>> DVB-T [card=18] >>> [ 8.492094] cx88[0]/2: cx2388x based DVB/ATSC card >>> [ 8.492095] cx8802_alloc_frontends() allocating 1 frontend(s) >>> [ 8.618036] DVB: registering new adapter (cx88[0]) >>> >>> [root@DESKTOP /]# lspci | grep Conexant >>> 05:05.0 Multimedia video controller: Conexant Systems, Inc. >>> CX23880/1/2/3 >>> PCI Video and Audio Decoder (rev 05) >>> 05:05.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI >>> Video and Audio Decoder [MPEG Port] (rev 05) >>> 05:05.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI >>> Video and Audio Decoder [IR Port] (rev 05) >>> >>> Thanks, Krister >>> -------------------------------------------------- >>> From: "Jarod Wilson"<ja...@wi...> >>> Sent: Monday, April 18, 2011 11:09 PM >>> To: "Krister Hallergard"<kr...@ha...> >>> Cc: "mailing list: lirc"<lir...@li...> >>> Subject: Re: Lirc damon running but no output in Fedora 14 >>> >>>> On Apr 18, 2011, at 5:27 PM, Krister Hallergard wrote: >>>> >>>>> Thank you Jarod, I trust you. Got your message re hardware.conf (use >>>>> /etc/sysconfig/lirc instead?), and have tried without it, but the >>>>> situation does not change. Using Hauppauge Nova-T-PCI and their gray >>>>> 45 >>>>> button remote. >>>> Please keep the discussion on the mailing list. I do have an idea of >>>> what might be going on there though, will need to check some code to >>>> see if the theory pans out. Will also need lspci and relevant dmesg >>>> output surrounding device bring-up after boot. >>>> >>>> >>>>> -------------------------------------------------- >>>>> From: "Jarod Wilson"<ja...@wi...> >>>>> Sent: Monday, April 18, 2011 8:00 PM >>>>> To: "Krister Hallergard"<kr...@ha...> >>>>> Cc:<lir...@li...> >>>>> Subject: Re: Lirc damon running but no output in Fedora 14 >>>>> >>>>>> On Apr 18, 2011, at 2:08 PM, Krister Hallergard wrote: >>>>>> >>>>>>> Thought the reason for LIRC was not working with F14 was that the >>>>>>> kernel changes for lirc had not been properly implemented, but still >>>>>>> cannot get it working with the latest >>>>>>> kernel-2.6.35.12-88.fc14.i686.PAE. Using latest version >>>>>>> lirc-0.9.0-1..fc14 (i686). >>>>>> Trust me, the lirc code in F14 is properly implemented... :) >>>>>> >>>>>> >>>>>>> Checking lirc status (/etc/init.d/lirc status) gives "lircd (pid >>>>>>> 1538) >>>>>>> is running..." >>>>>>> ls /dev/lirc* gives " lircd0" >>>>>>> ls /var/run/lirc gives "lircd lircd.pid" >>>>>>> >>>>>>> Activating with "irexec -d" and irxevent -d" it should be working - >>>>>>> but >>>>>>> it isn't - so I tried this in a root terminal: >>>>>>> Code: >>>>>>> rm /var/run/lirc/lircd.pid >>>>>>> /usr/sbin/lircd -H dev/input -d /dev/input/irremote -n >>>>>>> >>>>>>> And in another terminal: irw >>>>>>> pressing buttons gives no output, despite the first terminal >>>>>>> showing: >>>>>>> Code: >>>>>>> lircd-0.9.0[18223]: lircd(devinput) ready, using /var/run/lirc/lircd >>>>>>> lircd-0.9.0[18223]: accepted new client on /var/run/lirc/lircd >>>>>>> lircd-0.9.0[18223]: initializing '/dev/input/irremote' >>>>>>> >>>>>>> Everything else is that same as in F13 where LIRC works fine, >>>>>>> including >>>>>>> the KERNEL=="event*", ATTRS{vendor}=="0x14f1", >>>>>>> SYMLINK+="input/irremote" added to /etc/udev/10local.rules and >>>>>>> hardware.conf rather minimal: >>>>>>> Code: >>>>>>> LIRCD_ARGS="" >>>>>>> LOAD_MODULES=true >>>>>>> DRIVER="dev/input" >>>>>>> DEVICE="/dev/input/irremote" >>>>>>> MODULES="lirc_dev" >>>>>>> LIRCD_CONF="" >>>>>>> >>>>>>> Any suggestions would be very much appreciated >>>>>> Uh. hardware.conf? That's a Debian-ism. Not an upstream lirc thing. >>>>>> It >>>>>> has absolutely no meaning on a Fedora system. >>>>>> >>>>>> What IR hardware and what remote are you trying to use here? >>>> -- >>>> Jarod Wilson >>>> ja...@wi... >>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 10.0.1321 / Virus Database: 1500/3582 - Release Date: 04/18/11 >>>> >>>> >>> ------------------------------------------------------------------------------ >>> Benefiting from Server Virtualization: Beyond Initial Workload >>> Consolidation -- Increasing the use of server virtualization is a top >>> priority.Virtualization can reduce costs, simplify management, and >>> improve >>> application availability and disaster protection. Learn more about >>> boosting >>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and >> improve >> application availability and disaster protection. Learn more about >> boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > -- > Jarod Wilson > ja...@wi... > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1321 / Virus Database: 1500/3583 - Release Date: 04/19/11 > > |
From: Jarod W. <ja...@wi...> - 2011-04-19 18:17:26
|
On Apr 19, 2011, at 12:25 PM, Krister Hallergard wrote: > Thanks Douglas and Jarod. Yes this seems to be my problem. Close, but not quite... > [root@DESKTOP /]# dmesg | grep keymap > [ 6.916127] Registered IR keymap rc-hauppauge-new > > [root@DESKTOP /]# ps -ef | grep lircd > root 1527 1 0 17:00 ? 00:00:00 /usr/sbin/lircd --driver=dev/input --device=/dev/input/irremote > root 2772 2724 0 17:03 pts/3 00:00:00 grep --color=auto lircd > > No output - my /etc/lirc/lirc.conf is not recognized Have tried renaming is lirc.conf.devinput - no change. Have tried to copy over the file /usr/share/lirc-remotes/devinput/lirc.conf.devinput -no change. Should I generate my own lirc.conf.devinput? > > [root@DESKTOP mnt]# ir-keytable > Found /sys/class/rc/rc0/ (/dev/input/event5) with: > Driver cx88xx, table rc-hauppauge-new > Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC > Enabled protocols: LIRC > Repeat delay = 500 ms, repeat period = 33 ms > > There is not output with ir-keytable -t or ir-keytable -s rc0 -t Yeah, per the ir-keytable output, the in-kernel decoders are all disabled, only the lirc bridge (which feeds data out to userspace via /dev/lirc0) is active. That's due to some bits in the latest Fedora lirc initscript, which obviously needs some fine-tuning so that its not doing that in the devinput case... So what's happening here is that you're trying to use devinput mode, but devinput mode won't ever yield any data, because the in-kernel decoders are disabled, so the IR is never decoded and matched against the in-kernel lookup tables to map to input events. For the moment, you'll need to either tweak /etc/init.d/lirc to not disable the native in-kernel decoders, or switch to using the lirc interface. I'll try to get the initscript fixed up so that it doesn't do such brain-dead things. Heh. So the IR *code* is all correct, but the initscript is doing something less-than-helpful in this case... :) > [root@DESKTOP /]# evtest /dev/input/event5 > Input driver version is 1.0.0 > Input device ID: bus 0x1 vendor 0x70 product 0x9002 version 0x1 > Input device name: "cx88 IR (Hauppauge Nova-T DVB-T" > Supported events: > Event type 0 (Sync) > Event type 1 (Key) ... > Event type 4 (Misc) > Event code 4 (ScanCode) > Event type 20 (Repeat) > Testing ... (interrupt to exit) > *********************************************** > This device is grabbed by another process. > No events are available to evtest while the > other grab is active. > In most cases, this is caused by an X driver, > try VT-switching and re-run evtest again. > *********************************************** > Wonder what the above means?? lircd has probably already grabbed it. -- Jarod Wilson ja...@wi... |
From: Krister H. <kr...@ha...> - 2011-04-19 18:43:47
|
Jarod, I am afraid I do not know how to tweak /etc/init.d/lirc to not disable the native in-kernel decoders, nor how to switch to using the lirc interface. I would rather wait for your fix of the initscript . Thanks Krister -------------------------------------------------- From: "Jarod Wilson" <ja...@wi...> Sent: Tuesday, April 19, 2011 7:17 PM To: "Krister Hallergard" <kr...@ha...> Cc: <dcl...@op...>; <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On Apr 19, 2011, at 12:25 PM, Krister Hallergard wrote: > >> Thanks Douglas and Jarod. Yes this seems to be my problem. > > Close, but not quite... > >> [root@DESKTOP /]# dmesg | grep keymap >> [ 6.916127] Registered IR keymap rc-hauppauge-new >> >> [root@DESKTOP /]# ps -ef | grep lircd >> root 1527 1 0 17:00 ? 00:00:00 >> /usr/sbin/lircd --driver=dev/input --device=/dev/input/irremote >> root 2772 2724 0 17:03 pts/3 00:00:00 grep --color=auto lircd >> >> No output - my /etc/lirc/lirc.conf is not recognized Have tried renaming >> is lirc.conf.devinput - no change. Have tried to copy over the file >> /usr/share/lirc-remotes/devinput/lirc.conf.devinput -no change. Should I >> generate my own lirc.conf.devinput? >> >> [root@DESKTOP mnt]# ir-keytable >> Found /sys/class/rc/rc0/ (/dev/input/event5) with: >> Driver cx88xx, table rc-hauppauge-new >> Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC >> Enabled protocols: LIRC >> Repeat delay = 500 ms, repeat period = 33 ms >> >> There is not output with ir-keytable -t or ir-keytable -s rc0 -t > > Yeah, per the ir-keytable output, the in-kernel decoders are all > disabled, only the lirc bridge (which feeds data out to userspace > via /dev/lirc0) is active. That's due to some bits in the latest > Fedora lirc initscript, which obviously needs some fine-tuning so > that its not doing that in the devinput case... > > So what's happening here is that you're trying to use devinput mode, > but devinput mode won't ever yield any data, because the in-kernel > decoders are disabled, so the IR is never decoded and matched against > the in-kernel lookup tables to map to input events. For the moment, > you'll need to either tweak /etc/init.d/lirc to not disable the native > in-kernel decoders, or switch to using the lirc interface. > > I'll try to get the initscript fixed up so that it doesn't do such > brain-dead things. Heh. So the IR *code* is all correct, but the > initscript is doing something less-than-helpful in this case... :) > > >> [root@DESKTOP /]# evtest /dev/input/event5 >> Input driver version is 1.0.0 >> Input device ID: bus 0x1 vendor 0x70 product 0x9002 version 0x1 >> Input device name: "cx88 IR (Hauppauge Nova-T DVB-T" >> Supported events: >> Event type 0 (Sync) >> Event type 1 (Key) > .... >> Event type 4 (Misc) >> Event code 4 (ScanCode) >> Event type 20 (Repeat) >> Testing ... (interrupt to exit) >> *********************************************** >> This device is grabbed by another process. >> No events are available to evtest while the >> other grab is active. >> In most cases, this is caused by an X driver, >> try VT-switching and re-run evtest again. >> *********************************************** >> Wonder what the above means?? > > lircd has probably already grabbed it. > > > -- > Jarod Wilson > ja...@wi... > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1321 / Virus Database: 1500/3583 - Release Date: 04/19/11 > > |
From: Jarod W. <ja...@wi...> - 2011-04-19 19:16:10
|
On Apr 19, 2011, at 2:43 PM, Krister Hallergard wrote: > > Jarod, I am afraid I do not know how to tweak /etc/init.d/lirc to not disable the native in-kernel decoders, nor how to switch to using the lirc interface. > I would rather wait for your fix of the initscript . Its actually pretty straight-forward to disable the disabling, just comment out the bits at the tail end of the start() function, which do the 'echo lirc > ${rc}'. It'll be a bit before I can sit down and fully flesh out a complete fix here, too many other tasks at hand right now... > -------------------------------------------------- > From: "Jarod Wilson" <ja...@wi...> > Sent: Tuesday, April 19, 2011 7:17 PM > To: "Krister Hallergard" <kr...@ha...> > Cc: <dcl...@op...>; <lir...@li...> > Subject: Re: Lirc damon running but no output in Fedora 14 > >> On Apr 19, 2011, at 12:25 PM, Krister Hallergard wrote: >> >>> Thanks Douglas and Jarod. Yes this seems to be my problem. >> >> Close, but not quite... >> >>> [root@DESKTOP /]# dmesg | grep keymap >>> [ 6.916127] Registered IR keymap rc-hauppauge-new >>> >>> [root@DESKTOP /]# ps -ef | grep lircd >>> root 1527 1 0 17:00 ? 00:00:00 /usr/sbin/lircd --driver=dev/input --device=/dev/input/irremote >>> root 2772 2724 0 17:03 pts/3 00:00:00 grep --color=auto lircd >>> >>> No output - my /etc/lirc/lirc.conf is not recognized Have tried renaming is lirc.conf.devinput - no change. Have tried to copy over the file /usr/share/lirc-remotes/devinput/lirc.conf.devinput -no change. Should I generate my own lirc.conf.devinput? >>> >>> [root@DESKTOP mnt]# ir-keytable >>> Found /sys/class/rc/rc0/ (/dev/input/event5) with: >>> Driver cx88xx, table rc-hauppauge-new >>> Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC >>> Enabled protocols: LIRC >>> Repeat delay = 500 ms, repeat period = 33 ms >>> >>> There is not output with ir-keytable -t or ir-keytable -s rc0 -t >> >> Yeah, per the ir-keytable output, the in-kernel decoders are all >> disabled, only the lirc bridge (which feeds data out to userspace >> via /dev/lirc0) is active. That's due to some bits in the latest >> Fedora lirc initscript, which obviously needs some fine-tuning so >> that its not doing that in the devinput case... >> >> So what's happening here is that you're trying to use devinput mode, >> but devinput mode won't ever yield any data, because the in-kernel >> decoders are disabled, so the IR is never decoded and matched against >> the in-kernel lookup tables to map to input events. For the moment, >> you'll need to either tweak /etc/init.d/lirc to not disable the native >> in-kernel decoders, or switch to using the lirc interface. >> >> I'll try to get the initscript fixed up so that it doesn't do such >> brain-dead things. Heh. So the IR *code* is all correct, but the >> initscript is doing something less-than-helpful in this case... :) >> >> >>> [root@DESKTOP /]# evtest /dev/input/event5 >>> Input driver version is 1.0.0 >>> Input device ID: bus 0x1 vendor 0x70 product 0x9002 version 0x1 >>> Input device name: "cx88 IR (Hauppauge Nova-T DVB-T" >>> Supported events: >>> Event type 0 (Sync) >>> Event type 1 (Key) >> .... >>> Event type 4 (Misc) >>> Event code 4 (ScanCode) >>> Event type 20 (Repeat) >>> Testing ... (interrupt to exit) >>> *********************************************** >>> This device is grabbed by another process. >>> No events are available to evtest while the >>> other grab is active. >>> In most cases, this is caused by an X driver, >>> try VT-switching and re-run evtest again. >>> *********************************************** >>> Wonder what the above means?? >> >> lircd has probably already grabbed it. >> >> >> -- >> Jarod Wilson >> ja...@wi... >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1321 / Virus Database: 1500/3583 - Release Date: 04/19/11 >> -- Jarod Wilson ja...@wi... |
From: Krister H. <kr...@ha...> - 2011-04-19 22:12:31
|
Thanks Jarod, but I still get no output after commenting out the lines at the end of the start() function: # if [ $retval -eq 0 ]; then # rcs=$(find -L /sys/class/rc/ -maxdepth 2 -name protocols 2> /dev/null) # for rc in $rcs # do # echo lirc > ${rc} # done # fi # return $retval Did I missunderstand the hack? Cheers Krister -------------------------------------------------- From: "Jarod Wilson" <ja...@wi...> Sent: Tuesday, April 19, 2011 8:16 PM To: "Krister Hallergard" <kr...@ha...> Cc: <dcl...@op...>; <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On Apr 19, 2011, at 2:43 PM, Krister Hallergard wrote: > >> >> Jarod, I am afraid I do not know how to tweak /etc/init.d/lirc to not >> disable the native in-kernel decoders, nor how to switch to using the >> lirc interface. >> I would rather wait for your fix of the initscript . > > Its actually pretty straight-forward to disable the disabling, > just comment out the bits at the tail end of the start() function, > which do the 'echo lirc > ${rc}'. It'll be a bit before I can sit > down and fully flesh out a complete fix here, too many other tasks > at hand right now... > > >> -------------------------------------------------- >> From: "Jarod Wilson" <ja...@wi...> >> Sent: Tuesday, April 19, 2011 7:17 PM >> To: "Krister Hallergard" <kr...@ha...> >> Cc: <dcl...@op...>; <lir...@li...> >> Subject: Re: Lirc damon running but no output in Fedora 14 >> >>> On Apr 19, 2011, at 12:25 PM, Krister Hallergard wrote: >>> >>>> Thanks Douglas and Jarod. Yes this seems to be my problem. >>> >>> Close, but not quite... >>> >>>> [root@DESKTOP /]# dmesg | grep keymap >>>> [ 6.916127] Registered IR keymap rc-hauppauge-new >>>> >>>> [root@DESKTOP /]# ps -ef | grep lircd >>>> root 1527 1 0 17:00 ? 00:00:00 >>>> /usr/sbin/lircd --driver=dev/input --device=/dev/input/irremote >>>> root 2772 2724 0 17:03 pts/3 00:00:00 grep --color=auto lircd >>>> >>>> No output - my /etc/lirc/lirc.conf is not recognized Have tried >>>> renaming is lirc.conf.devinput - no change. Have tried to copy over >>>> the file /usr/share/lirc-remotes/devinput/lirc.conf.devinput -no >>>> change. Should I generate my own lirc.conf.devinput? >>>> >>>> [root@DESKTOP mnt]# ir-keytable >>>> Found /sys/class/rc/rc0/ (/dev/input/event5) with: >>>> Driver cx88xx, table rc-hauppauge-new >>>> Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC >>>> Enabled protocols: LIRC >>>> Repeat delay = 500 ms, repeat period = 33 ms >>>> >>>> There is not output with ir-keytable -t or ir-keytable -s rc0 -t >>> >>> Yeah, per the ir-keytable output, the in-kernel decoders are all >>> disabled, only the lirc bridge (which feeds data out to userspace >>> via /dev/lirc0) is active. That's due to some bits in the latest >>> Fedora lirc initscript, which obviously needs some fine-tuning so >>> that its not doing that in the devinput case... >>> >>> So what's happening here is that you're trying to use devinput mode, >>> but devinput mode won't ever yield any data, because the in-kernel >>> decoders are disabled, so the IR is never decoded and matched against >>> the in-kernel lookup tables to map to input events. For the moment, >>> you'll need to either tweak /etc/init.d/lirc to not disable the native >>> in-kernel decoders, or switch to using the lirc interface. >>> >>> I'll try to get the initscript fixed up so that it doesn't do such >>> brain-dead things. Heh. So the IR *code* is all correct, but the >>> initscript is doing something less-than-helpful in this case... :) >>> >>> >>>> [root@DESKTOP /]# evtest /dev/input/event5 >>>> Input driver version is 1.0.0 >>>> Input device ID: bus 0x1 vendor 0x70 product 0x9002 version 0x1 >>>> Input device name: "cx88 IR (Hauppauge Nova-T DVB-T" >>>> Supported events: >>>> Event type 0 (Sync) >>>> Event type 1 (Key) >>> .... >>>> Event type 4 (Misc) >>>> Event code 4 (ScanCode) >>>> Event type 20 (Repeat) >>>> Testing ... (interrupt to exit) >>>> *********************************************** >>>> This device is grabbed by another process. >>>> No events are available to evtest while the >>>> other grab is active. >>>> In most cases, this is caused by an X driver, >>>> try VT-switching and re-run evtest again. >>>> *********************************************** >>>> Wonder what the above means?? >>> >>> lircd has probably already grabbed it. >>> >>> >>> -- >>> Jarod Wilson >>> ja...@wi... >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 10.0.1321 / Virus Database: 1500/3583 - Release Date: 04/19/11 >>> > > -- > Jarod Wilson > ja...@wi... > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1321 / Virus Database: 1500/3583 - Release Date: 04/19/11 > > |
From: Douglas C. <dcl...@op...> - 2011-04-20 13:39:39
|
On 2011-04-20 08:12, Krister Hallergard wrote: > Thanks Jarod, but I still get no output after commenting out the lines > at the end of the start() function: > # if [ $retval -eq 0 ]; then > # rcs=$(find -L /sys/class/rc/ -maxdepth 2 -name protocols 2> > /dev/null) > # for rc in $rcs > # do > # echo lirc > ${rc} > # done > # fi > # return $retval > Did I missunderstand the hack? > Cheers > Krister Did you reboot or just restart lirc? It would have been helpful to see what ir-keytable said. It looks like your receiver is raw IR. My cx88 card is scancode (I assume that's why there's no protocols). My other system is raw IR and ir-keytable output looks like this: # ir-keytable Found /sys/class/rc/rc2/ (/dev/input/event4) with: Driver nuvoton-cir, table rc-rc6-mce Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: NEC Repeat delay = 500 ms, repeat period = 33 ms The enabled protocols by default are incorrect but after I load my keytable they change to NEC and I get keycodes. Before that I only get scancodes. I can enable additional protocols thus: # ir-keytable -s rc2 -p RC-5 -pRC-6 -pNEC Protocols changed to NEC RC-5 RC-6 # ir-keytable Found /sys/class/rc/rc2/ (/dev/input/event4) with: Driver nuvoton-cir, table rc-rc6-mce Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: NEC RC-5 RC-6 Repeat delay = 500 ms, repeat period = 33 ms I don't know what the correct protocol is for your remote. You could try each of the supported protocols until you start getting scancodes. Then try a different keytable (ir-keytable -s rcN -c -w /etc/rc_keymaps/haupp) until you get keycodes, then add in the lirc bridge from /dev/input/eventN to /var/run/lirc/lircd with lirc.conf.devinput and, if you get that far, irw should also produce output. You then need a ~/.lircrc file to map what irw sees to what your program is looking for. I am new at this. I'm still working on my own setup, so don't pay too much attention to me :) Hope it helps. Douglas > -------------------------------------------------- > From: "Jarod Wilson" <ja...@wi...> > Sent: Tuesday, April 19, 2011 8:16 PM > To: "Krister Hallergard" <kr...@ha...> > Cc: <dcl...@op...>; <lir...@li...> > Subject: Re: Lirc damon running but no output in Fedora 14 > >> On Apr 19, 2011, at 2:43 PM, Krister Hallergard wrote: >> >>> >>> Jarod, I am afraid I do not know how to tweak /etc/init.d/lirc to >>> not disable the native in-kernel decoders, nor how to switch to >>> using the lirc interface. >>> I would rather wait for your fix of the initscript . >> >> Its actually pretty straight-forward to disable the disabling, >> just comment out the bits at the tail end of the start() function, >> which do the 'echo lirc > ${rc}'. It'll be a bit before I can sit >> down and fully flesh out a complete fix here, too many other tasks >> at hand right now... |
From: Krister H. <kr...@ha...> - 2011-04-20 15:21:06
|
Thanks Douglas. I did reboot. Did not include the ir-keytable output as it was the same as before hacking /etc/init.d/lirc. Being a newbe I am afraid that I do not really understand what you are saying about protocols, loading keytables, lirc bridge etc. I do have lircd.conf and ~/.lircrc, the same as worked well on F13. Cheers, Krister -------------------------------------------------- From: "Douglas Clowes" <dcl...@op...> Sent: Wednesday, April 20, 2011 2:38 PM To: "Krister Hallergard" <kr...@ha...> Cc: "Jarod Wilson" <ja...@wi...>; <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On 2011-04-20 08:12, Krister Hallergard wrote: >> Thanks Jarod, but I still get no output after commenting out the lines at >> the end of the start() function: >> # if [ $retval -eq 0 ]; then >> # rcs=$(find -L /sys/class/rc/ -maxdepth 2 -name protocols 2> >> /dev/null) >> # for rc in $rcs >> # do >> # echo lirc > ${rc} >> # done >> # fi >> # return $retval >> Did I missunderstand the hack? >> Cheers >> Krister > Did you reboot or just restart lirc? It would have been helpful to see > what ir-keytable said. > > It looks like your receiver is raw IR. My cx88 card is scancode (I assume > that's why there's no protocols). > > My other system is raw IR and ir-keytable output looks like this: > # ir-keytable > Found /sys/class/rc/rc2/ (/dev/input/event4) with: > Driver nuvoton-cir, table rc-rc6-mce > Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC > Enabled protocols: NEC > Repeat delay = 500 ms, repeat period = 33 ms > The enabled protocols by default are incorrect but after I load my > keytable they change to NEC and I get keycodes. Before that I only get > scancodes. > I can enable additional protocols thus: > # ir-keytable -s rc2 -p RC-5 -pRC-6 -pNEC > Protocols changed to NEC RC-5 RC-6 > # ir-keytable > Found /sys/class/rc/rc2/ (/dev/input/event4) with: > Driver nuvoton-cir, table rc-rc6-mce > Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC > Enabled protocols: NEC RC-5 RC-6 > Repeat delay = 500 ms, repeat period = 33 ms > > I don't know what the correct protocol is for your remote. You could try > each of the supported protocols until you start getting scancodes. Then > try a different keytable (ir-keytable -s rcN -c -w /etc/rc_keymaps/haupp) > until you get keycodes, then add in the lirc bridge from /dev/input/eventN > to /var/run/lirc/lircd with lirc.conf.devinput and, if you get that far, > irw should also produce output. > > You then need a ~/.lircrc file to map what irw sees to what your program > is looking for. > > I am new at this. I'm still working on my own setup, so don't pay too much > attention to me :) > > Hope it helps. > > Douglas >> -------------------------------------------------- >> From: "Jarod Wilson" <ja...@wi...> >> Sent: Tuesday, April 19, 2011 8:16 PM >> To: "Krister Hallergard" <kr...@ha...> >> Cc: <dcl...@op...>; <lir...@li...> >> Subject: Re: Lirc damon running but no output in Fedora 14 >> >>> On Apr 19, 2011, at 2:43 PM, Krister Hallergard wrote: >>> >>>> >>>> Jarod, I am afraid I do not know how to tweak /etc/init.d/lirc to not >>>> disable the native in-kernel decoders, nor how to switch to using the >>>> lirc interface. >>>> I would rather wait for your fix of the initscript . >>> >>> Its actually pretty straight-forward to disable the disabling, >>> just comment out the bits at the tail end of the start() function, >>> which do the 'echo lirc > ${rc}'. It'll be a bit before I can sit >>> down and fully flesh out a complete fix here, too many other tasks >>> at hand right now... > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1321 / Virus Database: 1500/3585 - Release Date: 04/20/11 > |
From: Jarod W. <ja...@wi...> - 2011-04-20 15:33:38
|
On Apr 19, 2011, at 6:12 PM, Krister Hallergard wrote: > Thanks Jarod, but I still get no output after commenting out the lines at the end of the start() function: > # if [ $retval -eq 0 ]; then > # rcs=$(find -L /sys/class/rc/ -maxdepth 2 -name protocols 2> /dev/null) > # for rc in $rcs > # do > # echo lirc > ${rc} > # done > # fi > # return $retval > Did I missunderstand the hack? Uncomment the final 'return $retval' line, and you've got it. Can you provide ir-keytable output after a fresh boot with that change in place? Something goofy still seems to be going on here. (Also, please refrain from top-posting, it really does a number on readability of the discussion) -- Jarod Wilson ja...@wi... |
From: Krister H. <kr...@ha...> - 2011-04-20 16:41:11
|
From: "Jarod Wilson" <ja...@wi...> Sent: Wednesday, April 20, 2011 4:33 PM To: "Krister Hallergard" <kr...@ha...> Cc: <dcl...@op...>; <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On Apr 19, 2011, at 6:12 PM, Krister Hallergard wrote: > >> Thanks Jarod, but I still get no output after commenting out the lines at >> the end of the start() function: >> # if [ $retval -eq 0 ]; then >> # rcs=$(find -L /sys/class/rc/ -maxdepth 2 -name protocols 2> >> /dev/null) >> # for rc in $rcs >> # do >> # echo lirc > ${rc} >> # done >> # fi >> # return $retval >> Did I missunderstand the hack? > > Uncomment the final 'return $retval' line, and you've got it. Can you > provide ir-keytable output after a fresh boot with that change in > place? Something goofy still seems to be going on here. > > (Also, please refrain from top-posting, it really does a number on > readability of the discussion) Sorry, the default of my Email program > > > -- > Jarod Wilson > ja...@wi... > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1321 / Virus Database: 1500/3585 - Release Date: 04/20/11 > > Thanks Jarod. Uncommenting the final 'return $retval' line and rebooting: [root@DESKTOP /]# ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event5) with: Driver cx88xx, table rc-hauppauge-new Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC Enabled protocols: NEC RC-5 RC-6 JVC SONY LIRC Repeat delay = 500 ms, repeat period = 33 ms Believe the protocol of my remote is RC-5 Cheers, Krister |
From: Jarod W. <ja...@wi...> - 2011-04-20 17:18:43
|
On Apr 20, 2011, at 12:40 PM, Krister Hallergard wrote: > From: "Jarod Wilson" <ja...@wi...> > Sent: Wednesday, April 20, 2011 4:33 PM > To: "Krister Hallergard" <kr...@ha...> > Cc: <dcl...@op...>; <lir...@li...> > Subject: Re: Lirc damon running but no output in Fedora 14 > >> On Apr 19, 2011, at 6:12 PM, Krister Hallergard wrote: >> >>> Thanks Jarod, but I still get no output after commenting out the lines at the end of the start() function: >>> # if [ $retval -eq 0 ]; then >>> # rcs=$(find -L /sys/class/rc/ -maxdepth 2 -name protocols 2> /dev/null) >>> # for rc in $rcs >>> # do >>> # echo lirc > ${rc} >>> # done >>> # fi >>> # return $retval >>> Did I missunderstand the hack? >> >> Uncomment the final 'return $retval' line, and you've got it. Can you >> provide ir-keytable output after a fresh boot with that change in >> place? Something goofy still seems to be going on here. ... > Thanks Jarod. Uncommenting the final 'return $retval' line and rebooting: > [root@DESKTOP /]# ir-keytable > Found /sys/class/rc/rc0/ (/dev/input/event5) with: > Driver cx88xx, table rc-hauppauge-new > Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC > Enabled protocols: NEC RC-5 RC-6 JVC SONY LIRC > Repeat delay = 500 ms, repeat period = 33 ms > Believe the protocol of my remote is RC-5 Correct, the Hauppauge remotes are RC-5. We're inching closer here. The last piece of the puzzle now makes sense too. Your device does raw IR, meaning the in-kernel RC-5 decoder will spit out scancodes that contain a full RC-5 signal, device code and button code. There are other Hauppauge devices with hardware-based IR decoders, and we talk to those by way of e.g. ir-kbd-i2c. They pass along scancodes, rather than raw IR. In the case of ir-kbd-i2c, in 2.6.35, it actually strips off the device code. So for example, the full RC-5 scancode for KEY_TV is 0x1e1c (for at least some Hauppauge remotes). With your hardware, the decoder will spit out that exact value, which is what we'll look up in the scancode table. In the 2.6.35 ir-kbd-2c case, the 0x1e gets stripped off the front, and we only use 0x1c for the lookup. The rc-hauppauge-new table in this kernel has the button-code-only scancodes in it, so when your signal is decoded to a full RC-5 signal, it can't be matched. :\ This is fixed now upstream though. ir-kbd-i2c now passes along the device code as well, and the keymap uses the full RC-5 signal for both the raw IR and scancode based lookups. So you have a few choices here... 1) forget using devinput atm, just use the remote via /dev/lirc0 2) use ir-keytable to upload a new keymap (must be done every boot) 3) upgrade to a newer kernel (the latest Fedora 15 build should do) -- Jarod Wilson ja...@wi... |
From: Krister H. <kr...@ha...> - 2011-04-20 17:38:44
|
From: "Jarod Wilson" <ja...@wi...> Sent: Wednesday, April 20, 2011 6:18 PM To: "Krister Hallergard" <kr...@ha...> Cc: <dcl...@op...>; <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On Apr 20, 2011, at 12:40 PM, Krister Hallergard wrote: > >> From: "Jarod Wilson" <ja...@wi...> >> Sent: Wednesday, April 20, 2011 4:33 PM >> To: "Krister Hallergard" <kr...@ha...> >> Cc: <dcl...@op...>; <lir...@li...> >> Subject: Re: Lirc damon running but no output in Fedora 14 >> >>> On Apr 19, 2011, at 6:12 PM, Krister Hallergard wrote: >>> >>>> Thanks Jarod, but I still get no output after commenting out the lines >>>> at the end of the start() function: >>>> # if [ $retval -eq 0 ]; then >>>> # rcs=$(find -L /sys/class/rc/ -maxdepth 2 -name protocols 2> >>>> /dev/null) >>>> # for rc in $rcs >>>> # do >>>> # echo lirc > ${rc} >>>> # done >>>> # fi >>>> # return $retval >>>> Did I missunderstand the hack? >>> >>> Uncomment the final 'return $retval' line, and you've got it. Can you >>> provide ir-keytable output after a fresh boot with that change in >>> place? Something goofy still seems to be going on here. > .... >> Thanks Jarod. Uncommenting the final 'return $retval' line and >> rebooting: >> [root@DESKTOP /]# ir-keytable >> Found /sys/class/rc/rc0/ (/dev/input/event5) with: >> Driver cx88xx, table rc-hauppauge-new >> Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC >> Enabled protocols: NEC RC-5 RC-6 JVC SONY LIRC >> Repeat delay = 500 ms, repeat period = 33 ms >> Believe the protocol of my remote is RC-5 > > Correct, the Hauppauge remotes are RC-5. We're inching closer here. The > last piece of the puzzle now makes sense too. Your device does raw IR, > meaning the in-kernel RC-5 decoder will spit out scancodes that contain > a full RC-5 signal, device code and button code. > > There are other Hauppauge devices with hardware-based IR decoders, and > we talk to those by way of e.g. ir-kbd-i2c. They pass along scancodes, > rather than raw IR. In the case of ir-kbd-i2c, in 2.6.35, it actually > strips off the device code. So for example, the full RC-5 scancode for > KEY_TV is 0x1e1c (for at least some Hauppauge remotes). With your > hardware, the decoder will spit out that exact value, which is what > we'll look up in the scancode table. In the 2.6.35 ir-kbd-2c case, the > 0x1e gets stripped off the front, and we only use 0x1c for the lookup. > > The rc-hauppauge-new table in this kernel has the button-code-only > scancodes in it, so when your signal is decoded to a full RC-5 signal, > it can't be matched. :\ > > This is fixed now upstream though. ir-kbd-i2c now passes along the > device code as well, and the keymap uses the full RC-5 signal for both > the raw IR and scancode based lookups. > > So you have a few choices here... > > 1) forget using devinput atm, just use the remote via /dev/lirc0 > 2) use ir-keytable to upload a new keymap (must be done every boot) > 3) upgrade to a newer kernel (the latest Fedora 15 build should do) > > > > -- > Jarod Wilson > ja...@wi... > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1321 / Virus Database: 1500/3585 - Release Date: 04/20/11 > > Thanks Jarod, I am leaning toward alt 3 - the Fedora 15 release, but I am a bit curious about alt 1. How to do that? Take away my entries to /etc/sysconfig/lirc (LIRC_DRIVER="dev/input" and LIRC_DEVICE="/dev/input/irremote") and take away /etc/udev/10local.rules (KERNEL=="event*", ATTRS{vendor}=="0x14f1", SYMLINK+="input/irremote")? Anything else? Cheers, Krister |
From: Jarod W. <ja...@wi...> - 2011-04-20 18:36:03
|
On Apr 20, 2011, at 1:38 PM, Krister Hallergard wrote: ... >>> Thanks Jarod. Uncommenting the final 'return $retval' line and rebooting: >>> [root@DESKTOP /]# ir-keytable >>> Found /sys/class/rc/rc0/ (/dev/input/event5) with: >>> Driver cx88xx, table rc-hauppauge-new >>> Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC >>> Enabled protocols: NEC RC-5 RC-6 JVC SONY LIRC >>> Repeat delay = 500 ms, repeat period = 33 ms >>> Believe the protocol of my remote is RC-5 >> >> Correct, the Hauppauge remotes are RC-5. We're inching closer here. The >> last piece of the puzzle now makes sense too. Your device does raw IR, >> meaning the in-kernel RC-5 decoder will spit out scancodes that contain >> a full RC-5 signal, device code and button code. >> >> There are other Hauppauge devices with hardware-based IR decoders, and >> we talk to those by way of e.g. ir-kbd-i2c. They pass along scancodes, >> rather than raw IR. In the case of ir-kbd-i2c, in 2.6.35, it actually >> strips off the device code. So for example, the full RC-5 scancode for >> KEY_TV is 0x1e1c (for at least some Hauppauge remotes). With your >> hardware, the decoder will spit out that exact value, which is what >> we'll look up in the scancode table. In the 2.6.35 ir-kbd-2c case, the >> 0x1e gets stripped off the front, and we only use 0x1c for the lookup. >> >> The rc-hauppauge-new table in this kernel has the button-code-only >> scancodes in it, so when your signal is decoded to a full RC-5 signal, >> it can't be matched. :\ >> >> This is fixed now upstream though. ir-kbd-i2c now passes along the >> device code as well, and the keymap uses the full RC-5 signal for both >> the raw IR and scancode based lookups. >> >> So you have a few choices here... >> >> 1) forget using devinput atm, just use the remote via /dev/lirc0 >> 2) use ir-keytable to upload a new keymap (must be done every boot) >> 3) upgrade to a newer kernel (the latest Fedora 15 build should do) >> >> > Thanks Jarod, I am leaning toward alt 3 - the Fedora 15 release, Note that you don't need the full release, just the kernel. It should run just fine on top of a Fedora 14 install. > but I am a bit curious about alt 1. How to do that? Take away my entries to /etc/sysconfig/lirc (LIRC_DRIVER="dev/input" and LIRC_DEVICE="/dev/input/irremote") and take away /etc/udev/10local.rules (KERNEL=="event*", ATTRS{vendor}=="0x14f1", SYMLINK+="input/irremote")? Anything else? Change out your lircd.conf for the lircd.conf.hauppauge one in the lirc remotes directory/sub-package. That should be about it, I think. -- Jarod Wilson ja...@wi... |
From: Krister H. <kr...@ha...> - 2011-04-22 16:58:16
|
From: "Jarod Wilson" <ja...@wi...> Sent: Wednesday, April 20, 2011 7:35 PM To: "Krister Hallergard" <kr...@ha...> Cc: <dcl...@op...>; <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On Apr 20, 2011, at 1:38 PM, Krister Hallergard wrote: > .... >>>> Thanks Jarod. Uncommenting the final 'return $retval' line and >>>> rebooting: >>>> [root@DESKTOP /]# ir-keytable >>>> Found /sys/class/rc/rc0/ (/dev/input/event5) with: >>>> Driver cx88xx, table rc-hauppauge-new >>>> Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC >>>> Enabled protocols: NEC RC-5 RC-6 JVC SONY LIRC >>>> Repeat delay = 500 ms, repeat period = 33 ms >>>> Believe the protocol of my remote is RC-5 >>> >>> Correct, the Hauppauge remotes are RC-5. We're inching closer here. The >>> last piece of the puzzle now makes sense too. Your device does raw IR, >>> meaning the in-kernel RC-5 decoder will spit out scancodes that contain >>> a full RC-5 signal, device code and button code. >>> >>> There are other Hauppauge devices with hardware-based IR decoders, and >>> we talk to those by way of e.g. ir-kbd-i2c. They pass along scancodes, >>> rather than raw IR. In the case of ir-kbd-i2c, in 2.6.35, it actually >>> strips off the device code. So for example, the full RC-5 scancode for >>> KEY_TV is 0x1e1c (for at least some Hauppauge remotes). With your >>> hardware, the decoder will spit out that exact value, which is what >>> we'll look up in the scancode table. In the 2.6.35 ir-kbd-2c case, the >>> 0x1e gets stripped off the front, and we only use 0x1c for the lookup. >>> >>> The rc-hauppauge-new table in this kernel has the button-code-only >>> scancodes in it, so when your signal is decoded to a full RC-5 signal, >>> it can't be matched. :\ >>> >>> This is fixed now upstream though. ir-kbd-i2c now passes along the >>> device code as well, and the keymap uses the full RC-5 signal for both >>> the raw IR and scancode based lookups. >>> >>> So you have a few choices here... >>> >>> 1) forget using devinput atm, just use the remote via /dev/lirc0 >>> 2) use ir-keytable to upload a new keymap (must be done every boot) >>> 3) upgrade to a newer kernel (the latest Fedora 15 build should do) >>> >>> >> Thanks Jarod, I am leaning toward alt 3 - the Fedora 15 release, > > Note that you don't need the full release, just the kernel. It should > run just fine on top of a Fedora 14 install. > >> but I am a bit curious about alt 1. How to do that? Take away my >> entries to /etc/sysconfig/lirc (LIRC_DRIVER="dev/input" and >> LIRC_DEVICE="/dev/input/irremote") and take away /etc/udev/10local.rules >> (KERNEL=="event*", ATTRS{vendor}=="0x14f1", SYMLINK+="input/irremote")? >> Anything else? > > Change out your lircd.conf for the lircd.conf.hauppauge one in the lirc > remotes directory/sub-package. That should be about it, I think. > > -- > Jarod Wilson > ja...@wi... > Computer taken over by granchildren, but finally could change out my lircd.conf for the lircd.conf.hauppauge ones (tried them all). I still do not get any remote output. Yes, did match name in .lircrc [root@DESKTOP /]# ps -ef | grep lircd root 1556 1 0 17:52 ? 00:00:00 /usr/sbin/lircd --device=/dev/lirc0 root 4182 2794 0 17:59 pts/5 00:00:00 grep --color=auto lircd Douglas had a line with --output=/var/run/lirc/lircd /etc/lirc/lircd.conf.devinput should I not have thaat too? Cheers, Krister |
From: Jarod W. <ja...@wi...> - 2011-04-25 15:03:30
|
On Apr 22, 2011, at 12:57 PM, Krister Hallergard wrote: > From: "Jarod Wilson" <ja...@wi...> > Sent: Wednesday, April 20, 2011 7:35 PM > To: "Krister Hallergard" <kr...@ha...> > Cc: <dcl...@op...>; <lir...@li...> > Subject: Re: Lirc damon running but no output in Fedora 14 > >> On Apr 20, 2011, at 1:38 PM, Krister Hallergard wrote: >> .... >>>>> Thanks Jarod. Uncommenting the final 'return $retval' line and rebooting: >>>>> [root@DESKTOP /]# ir-keytable >>>>> Found /sys/class/rc/rc0/ (/dev/input/event5) with: >>>>> Driver cx88xx, table rc-hauppauge-new >>>>> Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC >>>>> Enabled protocols: NEC RC-5 RC-6 JVC SONY LIRC >>>>> Repeat delay = 500 ms, repeat period = 33 ms >>>>> Believe the protocol of my remote is RC-5 >>>> >>>> Correct, the Hauppauge remotes are RC-5. We're inching closer here. The >>>> last piece of the puzzle now makes sense too. Your device does raw IR, >>>> meaning the in-kernel RC-5 decoder will spit out scancodes that contain >>>> a full RC-5 signal, device code and button code. >>>> >>>> There are other Hauppauge devices with hardware-based IR decoders, and >>>> we talk to those by way of e.g. ir-kbd-i2c. They pass along scancodes, >>>> rather than raw IR. In the case of ir-kbd-i2c, in 2.6.35, it actually >>>> strips off the device code. So for example, the full RC-5 scancode for >>>> KEY_TV is 0x1e1c (for at least some Hauppauge remotes). With your >>>> hardware, the decoder will spit out that exact value, which is what >>>> we'll look up in the scancode table. In the 2.6.35 ir-kbd-2c case, the >>>> 0x1e gets stripped off the front, and we only use 0x1c for the lookup. >>>> >>>> The rc-hauppauge-new table in this kernel has the button-code-only >>>> scancodes in it, so when your signal is decoded to a full RC-5 signal, >>>> it can't be matched. :\ >>>> >>>> This is fixed now upstream though. ir-kbd-i2c now passes along the >>>> device code as well, and the keymap uses the full RC-5 signal for both >>>> the raw IR and scancode based lookups. >>>> >>>> So you have a few choices here... >>>> >>>> 1) forget using devinput atm, just use the remote via /dev/lirc0 >>>> 2) use ir-keytable to upload a new keymap (must be done every boot) >>>> 3) upgrade to a newer kernel (the latest Fedora 15 build should do) >>>> >>>> >>> Thanks Jarod, I am leaning toward alt 3 - the Fedora 15 release, >> >> Note that you don't need the full release, just the kernel. It should >> run just fine on top of a Fedora 14 install. >> >>> but I am a bit curious about alt 1. How to do that? Take away my entries to /etc/sysconfig/lirc (LIRC_DRIVER="dev/input" and LIRC_DEVICE="/dev/input/irremote") and take away /etc/udev/10local.rules (KERNEL=="event*", ATTRS{vendor}=="0x14f1", SYMLINK+="input/irremote")? Anything else? >> >> Change out your lircd.conf for the lircd.conf.hauppauge one in the lirc >> remotes directory/sub-package. That should be about it, I think. >> >> > Computer taken over by granchildren, but finally could change out my lircd.conf for the lircd.conf.hauppauge ones (tried them all). I still do not get any remote output. Hrm. The cx88 IR driver might be sending along IR samples in a way that lircd isn't so happy with. Do you get any output from mode2? > Yes, did match name in .lircrc > [root@DESKTOP /]# ps -ef | grep lircd > root 1556 1 0 17:52 ? 00:00:00 /usr/sbin/lircd --device=/dev/lirc0 > root 4182 2794 0 17:59 pts/5 00:00:00 grep --color=auto lircd > > Douglas had a line with --output=/var/run/lirc/lircd /etc/lirc/lircd.conf.devinput should I not have thaat too? Nope. The output value there is already the default, Douglas just has it explicitly called out, and /etc/lircd/lircd.conf is the default for the config file, Douglas is overriding that to point to the config file with the devinput suffix on it. -- Jarod Wilson ja...@wi... |
From: Krister H. <kr...@ha...> - 2011-04-25 17:42:19
|
From: "Jarod Wilson" <ja...@wi...> Sent: Monday, April 25, 2011 4:03 PM To: "Krister Hallergard" <kr...@ha...> Cc: <dcl...@op...>; <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On Apr 22, 2011, at 12:57 PM, Krister Hallergard wrote: > >> From: "Jarod Wilson" <ja...@wi...> >> Sent: Wednesday, April 20, 2011 7:35 PM >> To: "Krister Hallergard" <kr...@ha...> >> Cc: <dcl...@op...>; <lir...@li...> >> Subject: Re: Lirc damon running but no output in Fedora 14 >> >>> On Apr 20, 2011, at 1:38 PM, Krister Hallergard wrote: >>> .... >>>>>> Thanks Jarod. Uncommenting the final 'return $retval' line and >>>>>> rebooting: >>>>>> [root@DESKTOP /]# ir-keytable >>>>>> Found /sys/class/rc/rc0/ (/dev/input/event5) with: >>>>>> Driver cx88xx, table rc-hauppauge-new >>>>>> Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC >>>>>> Enabled protocols: NEC RC-5 RC-6 JVC SONY LIRC >>>>>> Repeat delay = 500 ms, repeat period = 33 ms >>>>>> Believe the protocol of my remote is RC-5 >>>>> >>>>> Correct, the Hauppauge remotes are RC-5. We're inching closer here. >>>>> The >>>>> last piece of the puzzle now makes sense too. Your device does raw IR, >>>>> meaning the in-kernel RC-5 decoder will spit out scancodes that >>>>> contain >>>>> a full RC-5 signal, device code and button code. >>>>> >>>>> There are other Hauppauge devices with hardware-based IR decoders, and >>>>> we talk to those by way of e.g. ir-kbd-i2c. They pass along scancodes, >>>>> rather than raw IR. In the case of ir-kbd-i2c, in 2.6.35, it actually >>>>> strips off the device code. So for example, the full RC-5 scancode for >>>>> KEY_TV is 0x1e1c (for at least some Hauppauge remotes). With your >>>>> hardware, the decoder will spit out that exact value, which is what >>>>> we'll look up in the scancode table. In the 2.6.35 ir-kbd-2c case, the >>>>> 0x1e gets stripped off the front, and we only use 0x1c for the lookup. >>>>> >>>>> The rc-hauppauge-new table in this kernel has the button-code-only >>>>> scancodes in it, so when your signal is decoded to a full RC-5 signal, >>>>> it can't be matched. :\ >>>>> >>>>> This is fixed now upstream though. ir-kbd-i2c now passes along the >>>>> device code as well, and the keymap uses the full RC-5 signal for both >>>>> the raw IR and scancode based lookups. >>>>> >>>>> So you have a few choices here... >>>>> >>>>> 1) forget using devinput atm, just use the remote via /dev/lirc0 >>>>> 2) use ir-keytable to upload a new keymap (must be done every boot) >>>>> 3) upgrade to a newer kernel (the latest Fedora 15 build should do) >>>>> >>>>> >>>> Thanks Jarod, I am leaning toward alt 3 - the Fedora 15 release, >>> >>> Note that you don't need the full release, just the kernel. It should >>> run just fine on top of a Fedora 14 install. >>> >>>> but I am a bit curious about alt 1. How to do that? Take away my >>>> entries to /etc/sysconfig/lirc (LIRC_DRIVER="dev/input" and >>>> LIRC_DEVICE="/dev/input/irremote") and take away >>>> /etc/udev/10local.rules (KERNEL=="event*", ATTRS{vendor}=="0x14f1", >>>> SYMLINK+="input/irremote")? Anything else? >>> >>> Change out your lircd.conf for the lircd.conf.hauppauge one in the lirc >>> remotes directory/sub-package. That should be about it, I think. >>> >>> >> Computer taken over by granchildren, but finally could change out my >> lircd.conf for the lircd.conf.hauppauge ones (tried them all). I still do >> not get any remote output. > > Hrm. The cx88 IR driver might be sending along IR samples in a way that > lircd isn't so happy with. Do you get any output from mode2? > > >> Yes, did match name in .lircrc >> [root@DESKTOP /]# ps -ef | grep lircd >> root 1556 1 0 17:52 ? 00:00:00 >> /usr/sbin/lircd --device=/dev/lirc0 >> root 4182 2794 0 17:59 pts/5 00:00:00 grep --color=auto lircd >> >> Douglas had a line with --output=/var/run/lirc/lircd >> /etc/lirc/lircd.conf.devinput should I not have thaat too? > > Nope. The output value there is already the default, Douglas just has it > explicitly called out, and /etc/lircd/lircd.conf is the default for the > config file, Douglas is overriding that to point to the config file with > the devinput suffix on it. > > -- > Jarod Wilson > ja...@wi... > No luck with mode2: [root@DESKTOP /]# mode2 mode2: could not open /dev/lirc0 mode2: default_init(): Device or resource busy It is only 2 weeks till the release of F15 - so I might as well wait for F15 and lirc will hopefully work straight out of the box. Thanks for your help, Jarod Krister |
From: Jarod W. <ja...@wi...> - 2011-04-25 18:18:13
|
On Apr 25, 2011, at 1:41 PM, Krister Hallergard wrote: ... >>> Computer taken over by granchildren, but finally could change out my lircd.conf for the lircd.conf.hauppauge ones (tried them all). I still do not get any remote output. >> >> Hrm. The cx88 IR driver might be sending along IR samples in a way that >> lircd isn't so happy with. Do you get any output from mode2? ... > No luck with mode2: > [root@DESKTOP /]# mode2 > mode2: could not open /dev/lirc0 > mode2: default_init(): Device or resource busy service lirc stop, then mode2 (and then whack a few remote buttons to get some output, of course). But as it turns out, I actually do have comparable hardware in my collection, I just need to liberate it from its current duties so I can test with it... > It is only 2 weeks till the release of F15 - so I might as well wait for F15 and lirc will hopefully work straight out of the box. Thanks for your help, Jarod Well, I still need to fix up the lirc initscript to not disable the in-kernel decoding for your setup, but it should otherwise hopefully come close to Just Works(tm) right out of the box... :) -- Jarod Wilson ja...@wi... |
From: Krister H. <kr...@ha...> - 2011-04-25 21:48:18
|
From: "Jarod Wilson" <ja...@wi...> Sent: Monday, April 25, 2011 7:18 PM To: "Krister Hallergard" <kr...@ha...> Cc: <dcl...@op...>; <lir...@li...> Subject: Re: Lirc damon running but no output in Fedora 14 > On Apr 25, 2011, at 1:41 PM, Krister Hallergard wrote: > .... >>>> Computer taken over by granchildren, but finally could change out my >>>> lircd.conf for the lircd.conf.hauppauge ones (tried them all). I still >>>> do not get any remote output. >>> >>> Hrm. The cx88 IR driver might be sending along IR samples in a way that >>> lircd isn't so happy with. Do you get any output from mode2? > .... >> No luck with mode2: >> [root@DESKTOP /]# mode2 >> mode2: could not open /dev/lirc0 >> mode2: default_init(): Device or resource busy > > service lirc stop, then mode2 (and then whack a few remote buttons > to get some output, of course). But as it turns out, I actually do > have comparable hardware in my collection, I just need to liberate > it from its current duties so I can test with it... > > >> It is only 2 weeks till the release of F15 - so I might as well wait for >> F15 and lirc will hopefully work straight out of the box. Thanks for >> your help, Jarod > > > Well, I still need to fix up the lirc initscript to not disable the > in-kernel decoding for your setup, but it should otherwise hopefully > come close to Just Works(tm) right out of the box... :) > > -- > Jarod Wilson > ja...@wi... > > service lirc stop, then mode2: [root@DESKTOP /]# mode2 space 7257 pulse 250 space 3665 pulse 250 space 4588 pulse 250 space 6334 pulse 250 space 274040 pulse 250 ........regardless of if I whack a few buttons or not. Actually when whacking a button it stops for fraction of a second and then continues forever Cheers, Krister |
From: Jarod W. <ja...@wi...> - 2011-04-27 04:12:23
|
On Apr 25, 2011, at 5:47 PM, Krister Hallergard wrote: > From: "Jarod Wilson" <ja...@wi...> > Sent: Monday, April 25, 2011 7:18 PM > To: "Krister Hallergard" <kr...@ha...> > Cc: <dcl...@op...>; <lir...@li...> > Subject: Re: Lirc damon running but no output in Fedora 14 > >> On Apr 25, 2011, at 1:41 PM, Krister Hallergard wrote: >> .... >>>>> Computer taken over by granchildren, but finally could change out my lircd.conf for the lircd.conf.hauppauge ones (tried them all). I still do not get any remote output. >>>> >>>> Hrm. The cx88 IR driver might be sending along IR samples in a way that >>>> lircd isn't so happy with. Do you get any output from mode2? >> .... >>> No luck with mode2: >>> [root@DESKTOP /]# mode2 >>> mode2: could not open /dev/lirc0 >>> mode2: default_init(): Device or resource busy >> >> service lirc stop, then mode2 (and then whack a few remote buttons >> to get some output, of course). But as it turns out, I actually do >> have comparable hardware in my collection, I just need to liberate >> it from its current duties so I can test with it... >> >> >>> It is only 2 weeks till the release of F15 - so I might as well wait for F15 and lirc will hopefully work straight out of the box. Thanks for your help, Jarod >> >> >> Well, I still need to fix up the lirc initscript to not disable the >> in-kernel decoding for your setup, but it should otherwise hopefully >> come close to Just Works(tm) right out of the box... :) >> >> -- >> Jarod Wilson >> ja...@wi... >> >> > service lirc stop, then mode2: > [root@DESKTOP /]# mode2 > space 7257 > pulse 250 > space 3665 > pulse 250 > space 4588 > pulse 250 > space 6334 > pulse 250 > space 274040 > pulse 250 > ........regardless of if I whack a few buttons or not. Actually when whacking a button it stops for fraction of a second and then continues forever Hrm. Raw IR mode with that hardware appears to be quite broken then. The pulse lengths should definitely be varying, and there should be no data when there is no IR signal. :\ -- Jarod Wilson ja...@wi... |