From: Jarod W. <ja...@wi...> - 2011-04-12 16:12:18
|
On Apr 12, 2011, at 9:18 AM, Douglas Clowes wrote: > On 2011-04-11 23:53, Douglas Clowes wrote: >> >> Wrote a little program to set the top two bits of CR 0x2C to "10" and >> interrupts all over the place. Seems the CIR pins (75 and 76) have to be >> enabled on this chip. Looks like that could belong in nvt_cir_ldev_init >> where you do the output pin selection. > I have added that code to the driver and it's looking good. Very cool. I overlooked some CIR bring-up stuff in the 667 doc I've got, it does indeed show a default value of 0x0a for CR 0x2c, and a need to set bits 7 and 6 to 1 and 0 respectively to enable CIR. The same register twiddles nothing but fan outputs on the 677, and its default value if 0xfc. By this point in the code though, we have the chip_major saved, so we can just conditionally or in 0x80 to that register, and I think we should be all good here. Something like this would presumably work: http://people.redhat.com/jwilson/misc/nvt-w83667hg-enable-cir.patch (With of course the removal of the chip id restriction in nvt_hw_detect). >> I can cat event2 and I get garbage when I press a key so something is >> happening. >> > The IR signal seems a little noisy, with numerous 50uS spikes and > decreasing frequency of 100uS, 150uS, 200uS and even a few 250uS in the > log. They appear as: > Apr 12 21:42:33 family kernel: [26576.095591] nvt_dump_rx_buf (len 17): > 0x85 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f > 0x7f 0x7f 0x80 > where there is a spike followed by a long space, sometimes containing > another spike like: > Apr 12 18:40:59 family kernel: [15681.980100] nvt_dump_rx_buf (len 24): > 0x84 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f > 0x7f 0x7f 0x43 0x82 0x7f 0x7f 0x4d 0x82 0x7f 0x7f > where the 0x84 is the primary spike and the 0x82 ones are secondary. > > I have covered the sensor and it doesn't seem to make a difference, so > probably not ambient noise. While probably not a major issue in a > running system, irrecord takes them as keypresses and gets confused. Huh, odd. I don't recall ever seeing any such issues with my hardware. > Speaking of irrecord, it doesn't seem to like the stream, even after > filtering sub-200uS pulses. Out of curiosity, are you filtering them driver-side? I wonder if there is an additional trigger level config register options somewhere that we need to set that would filter those out... > Can't learn, can't handle repeats. Works > much more better on the Philips eHome although the pulse train is > remarkably similar. Major difference, from what I can see, is that the > eHome has a leading 100000 space and trailing 600 pulse: > space 100000 > pulse 9000 > space 4350 > pulse 650 > space 1600 > pulse 600 > space 1600 > ... > pulse 650 > space 1600 > pulse 600 > space 39550 > pulse 8950 > space 2200 > pulse 600 > whilst the nuvoton has a leading 9000 pulse and a trailing long space: > pulse 9000 > space 4450 > pulse 600 > space 1600 > pulse 600 > space 1650 > ... > pulse 600 > space 1600 > pulse 600 > space 39700 > pulse 9000 > space 2200 > pulse 600 > space 95650 > pulse 9000 > space 2200 > pulse 600 > space 95250 > with the 9000/2200 pair being the repeat codes in both cases. > > Curious! Crap. One or the other of them is delivering the long space at the wrong time... I need to sort that out in my head, and get them behaving the same way there. Otherwise, the pulse trains do look more or less identical now. > The eHome is on a standard Fedora 14 while the nuvoton is on the built > drivers. > > The eHome appears in /dev/input/by-id but the nuvoton does not. >> Sometimes event2 disappears and I have to reload the module for it to >> reappear. Interrupts keep happening and the rc is still in /sys/class/rc >> showing event2. Not sure what makes that happen. >> > That seems to be related to trying to dump the event in various ways. > Maybe something deletes it when it closes it. Seems stable now that I've > stopped doing that. No idea on that one offhand. >> Not sure of the plumbing and how to get messages to ircat and irw, but >> I'll keep plugging. >> > Seems that events are popping up on /dev/input/eventN Can use evtest and/or ir-keytable -t to verify that what is popping up looks correct for the buttons you're pressing. > and /dev/lirc0 and > in mode2 and *something* is happening in irrecord, but nothing on irw yet. Does irw work if you just drop the pre-existing mceusb config in place? > This same remote looks remarkably different through the AF9015 and the > nuvoton and eHome but remarkably similar through the eHome and nuvoton. > Just an observation. I'm not familiar with the AF9015 hardware, but I did try to make the nuvoton-cir driver to behave as close as possible to the mceusb driver, using the same sample period and very similar buffer parsing routines. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-04-21 18:27:07
|
On Apr 12, 2011, at 12:12 PM, Jarod Wilson wrote: > On Apr 12, 2011, at 9:18 AM, Douglas Clowes wrote: ... >> Can't learn, can't handle repeats. Works >> much more better on the Philips eHome although the pulse train is >> remarkably similar. Major difference, from what I can see, is that the >> eHome has a leading 100000 space and trailing 600 pulse: >> space 100000 >> pulse 9000 >> space 4350 >> pulse 650 >> space 1600 >> pulse 600 >> space 1600 >> ... >> pulse 650 >> space 1600 >> pulse 600 >> space 39550 >> pulse 8950 >> space 2200 >> pulse 600 >> whilst the nuvoton has a leading 9000 pulse and a trailing long space: >> pulse 9000 >> space 4450 >> pulse 600 >> space 1600 >> pulse 600 >> space 1650 >> ... >> pulse 600 >> space 1600 >> pulse 600 >> space 39700 >> pulse 9000 >> space 2200 >> pulse 600 >> space 95650 >> pulse 9000 >> space 2200 >> pulse 600 >> space 95250 >> with the 9000/2200 pair being the repeat codes in both cases. >> >> Curious! > > Crap. One or the other of them is delivering the long space at the > wrong time... I need to sort that out in my head, and get them > behaving the same way there. Otherwise, the pulse trains do look > more or less identical now. I have a patch that switches nuvoton-cir over to using the same sample storing method as mceusb and streamzap, and now the long spaces are at the front end of the signals seen via the lirc interface, and irw works perfectly with the stock mceusb lircd.conf. -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-12 21:25:25
|
On 2011-04-13 02:12, Jarod Wilson wrote: > On Apr 12, 2011, at 9:18 AM, Douglas Clowes wrote: > >> On 2011-04-11 23:53, Douglas Clowes wrote: >>> Wrote a little program to set the top two bits of CR 0x2C to "10" and >>> interrupts all over the place. Seems the CIR pins (75 and 76) have to be >>> enabled on this chip. Looks like that could belong in nvt_cir_ldev_init >>> where you do the output pin selection. >> I have added that code to the driver and it's looking good. > Very cool. I overlooked some CIR bring-up stuff in the 667 doc I've > got, it does indeed show a default value of 0x0a for CR 0x2c, and > a need to set bits 7 and 6 to 1 and 0 respectively to enable CIR. > > The same register twiddles nothing but fan outputs on the 677, and > its default value if 0xfc. By this point in the code though, we have > the chip_major saved, so we can just conditionally or in 0x80 to > that register, and I think we should be all good here. Something like > this would presumably work: > > http://people.redhat.com/jwilson/misc/nvt-w83667hg-enable-cir.patch > > (With of course the removal of the chip id restriction in nvt_hw_detect). > > I don't think that register 0x27 (CR_OUTPUT_PIN_SEL) does the same thing on the 667 and 677. Indeed, register 0x2c on the 667 seems to have the bits that are in register 0x27 on the 677. Assuming that there will be others and that they will be different, I opted for: --- linux/drivers/media/rc/nuvoton-cir.h 2011-04-12 17:19:15.453586801 +1000 +++ ../nuvoton-cir.h 2011-04-12 08:34:34.695542755 +1000 @@ -95,6 +95,11 @@ int cir_irq; int cir_wake_irq; + /* pin select and enable */ + u8 pin_select_reg; + u8 pin_select_mask; + u8 pin_select_val; + /* hardware id */ u8 chip_major; u8 chip_minor; @@ -331,8 +336,10 @@ /* Chip IDs found in CR_CHIP_ID_{HI,LO} */ #define CHIP_ID_HIGH 0xb4 +#define CHIP_ID_HIGH3 0xa5 #define CHIP_ID_LOW 0x72 #define CHIP_ID_LOW2 0x73 +#define CHIP_ID_LOW3 0x13 /* Config regs we need to care about */ #define CR_SOFTWARE_RESET 0x02 @@ -341,6 +348,7 @@ #define CR_CHIP_ID_LO 0x21 #define CR_DEV_POWER_DOWN 0x22 /* bit 2 is CIR power, default power on */ #define CR_OUTPUT_PIN_SEL 0x27 +#define CR_OUTPUT_PIN_SEL2 0x2c #define CR_LOGICAL_DEV_EN 0x30 /* valid for all logical devices */ /* next three regs valid for both the CIR and CIR_WAKE logical devices */ #define CR_CIR_BASE_ADDR_HI 0x60 @@ -368,6 +376,10 @@ #define OUTPUT_ENABLE_CIR 0x01 /* Pin95=CIRRX, Pin96=CIRTX1 */ #define OUTPUT_ENABLE_CIRWB 0x40 /* enable wide-band sensor */ +#define OUTPUT_PIN_SEL_MASK2 0x1f +#define OUTPUT_ENABLE_CIR2 0x80 /* Pin75=CIRRX, Pin76=CIRTX */ +#define OUTPUT_ENABLE_CIRWB2 0x20 /* enable wide-band sensor */ + /* MCE CIR signal length, related on sample period */ /* MCE CIR controller signal length: about 43ms --- linux/drivers/media/rc/nuvoton-cir.c 2011-04-12 17:19:15.455586814 +1000 +++ ../nuvoton-cir.c 2011-04-12 17:18:27.307587605 +1000 @@ -248,8 +248,18 @@ chip_minor = nvt_cr_read(nvt, CR_CHIP_ID_LO); nvt_dbg("%s: chip id: 0x%02x 0x%02x", chip_id, chip_major, chip_minor); - if (chip_major != CHIP_ID_HIGH || - (chip_minor != CHIP_ID_LOW && chip_minor != CHIP_ID_LOW2)) { + if (chip_major == CHIP_ID_HIGH && + (chip_minor == CHIP_ID_LOW || chip_minor == CHIP_ID_LOW2)) { + nvt->pin_select_reg = CR_OUTPUT_PIN_SEL; + nvt->pin_select_mask = OUTPUT_PIN_SEL_MASK; + nvt->pin_select_val = OUTPUT_ENABLE_CIR | OUTPUT_ENABLE_CIRWB; + } else if (chip_major == CHIP_ID_HIGH3 && + (chip_minor == CHIP_ID_LOW3)) { + /* W83667HG-A */ + nvt->pin_select_reg = CR_OUTPUT_PIN_SEL2; + nvt->pin_select_mask = OUTPUT_PIN_SEL_MASK2; + nvt->pin_select_val = OUTPUT_ENABLE_CIR2 | OUTPUT_ENABLE_CIRWB2; + } else { nvt_pr(KERN_ERR, "%s: unsupported chip, id: 0x%02x 0x%02x", chip_id, chip_major, chip_minor); ret = -ENODEV; @@ -269,11 +279,13 @@ { u8 val; - /* output pin selection (Pin95=CIRRX, Pin96=CIRTX1, WB enabled */ - val = nvt_cr_read(nvt, CR_OUTPUT_PIN_SEL); - val &= OUTPUT_PIN_SEL_MASK; - val |= (OUTPUT_ENABLE_CIR | OUTPUT_ENABLE_CIRWB); - nvt_cr_write(nvt, val, CR_OUTPUT_PIN_SEL); + /* pin selection (Pin95=CIRRX, Pin96=CIRTX1, WB enabled */ + if (nvt->pin_select_reg != 0) { + val = nvt_cr_read(nvt, nvt->pin_select_reg); + val &= nvt->pin_select_mask; + val |= nvt->pin_select_val; + nvt_cr_write(nvt, val, nvt->pin_select_reg); + } /* Select CIR logical device and enable */ nvt_select_logical_dev(nvt, LOGICAL_DEV_CIR); @@ -606,6 +618,20 @@ count = nvt->pkts; nvt_dbg_verbose("Processing buffer of len %d", count); + if (count >= 4 && + nvt->buf[0] > 0x80 && + nvt->buf[0] < 0x84 && + nvt->buf[1] == 0x7f && + nvt->buf[2] == 0x7f && + nvt->buf[3] == 0x7f) { + nvt_dbg("Dropping short pulse with duration %d uS in %d pkts", + (nvt->buf[0] & BUF_LEN_MASK) + * SAMPLE_PERIOD, nvt->pkts); + nvt->pkts = 0; + nvt_dbg_verbose("%s done", __func__); + return; + } + init_ir_raw_event(&rawir); for (i = 0; i < count; i++) { this allows more chip-id and register combinations in the one place and the zero allows for the not needed case. The code for filtering short pulses is a hack at the moment, so ignore that, but there it is. >>> I can cat event2 and I get garbage when I press a key so something is >>> happening. >>> >> The IR signal seems a little noisy, with numerous 50uS spikes and >> decreasing frequency of 100uS, 150uS, 200uS and even a few 250uS in the >> log. They appear as: >> Apr 12 21:42:33 family kernel: [26576.095591] nvt_dump_rx_buf (len 17): >> 0x85 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f >> 0x7f 0x7f 0x80 >> where there is a spike followed by a long space, sometimes containing >> another spike like: >> Apr 12 18:40:59 family kernel: [15681.980100] nvt_dump_rx_buf (len 24): >> 0x84 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f >> 0x7f 0x7f 0x43 0x82 0x7f 0x7f 0x4d 0x82 0x7f 0x7f >> where the 0x84 is the primary spike and the 0x82 ones are secondary. >> >> I have covered the sensor and it doesn't seem to make a difference, so >> probably not ambient noise. While probably not a major issue in a >> running system, irrecord takes them as keypresses and gets confused. > Huh, odd. I don't recall ever seeing any such issues with my hardware. > > >> Speaking of irrecord, it doesn't seem to like the stream, even after >> filtering sub-200uS pulses. > Out of curiosity, are you filtering them driver-side? I wonder if there > is an additional trigger level config register options somewhere that > we need to set that would filter those out... > > There is the fifo value 0x00 for glitch pulse but I'm not seeing any of those, possibly because I haven't explicitly looked for them. You may also notice that register base+0xF is IRFSM and read-only. It is writable as IR Minimum length register. I did have a poke at that and was set the GH bit in register IRSTS. Presumably I could also get an interrupt. After that bit came on, it didn't seem to go off until power-cycled so I'm not actively pursuing that avenue at the moment. >> Can't learn, can't handle repeats. Works >> much more better on the Philips eHome although the pulse train is >> remarkably similar. Major difference, from what I can see, is that the >> eHome has a leading 100000 space and trailing 600 pulse: >> space 100000 >> pulse 9000 >> space 4350 >> pulse 650 >> space 1600 >> pulse 600 >> space 1600 >> ... >> pulse 650 >> space 1600 >> pulse 600 >> space 39550 >> pulse 8950 >> space 2200 >> pulse 600 >> whilst the nuvoton has a leading 9000 pulse and a trailing long space: >> pulse 9000 >> space 4450 >> pulse 600 >> space 1600 >> pulse 600 >> space 1650 >> ... >> pulse 600 >> space 1600 >> pulse 600 >> space 39700 >> pulse 9000 >> space 2200 >> pulse 600 >> space 95650 >> pulse 9000 >> space 2200 >> pulse 600 >> space 95250 >> with the 9000/2200 pair being the repeat codes in both cases. >> >> Curious! > Crap. One or the other of them is delivering the long space at the > wrong time... I need to sort that out in my head, and get them > behaving the same way there. Otherwise, the pulse trains do look > more or less identical now. > > I was thinking of doing something in the loop to both filter short transitions and merge the codes, instead of just looking at the low seven bits. So if this byte is the same type as last byte (pulse/space), just add duration else if long enough then send previous and change else just drop it. Prime this at the beginning with the long space which will get sent if there's a decent pulse at the start. If we get the 0x80 at the end and the saved duration is a space, just drop it. Something like that. That way, we have a long space to send first if the pulse is long enough, and it doesn't get sent if the pulse is short, even if there are multiple short pulses. >> The eHome is on a standard Fedora 14 while the nuvoton is on the built >> drivers. >> >> The eHome appears in /dev/input/by-id but the nuvoton does not. >>> Sometimes event2 disappears and I have to reload the module for it to >>> reappear. Interrupts keep happening and the rc is still in /sys/class/rc >>> showing event2. Not sure what makes that happen. >>> >> That seems to be related to trying to dump the event in various ways. >> Maybe something deletes it when it closes it. Seems stable now that I've >> stopped doing that. > No idea on that one offhand. > > >>> Not sure of the plumbing and how to get messages to ircat and irw, but >>> I'll keep plugging. >>> >> Seems that events are popping up on /dev/input/eventN > Can use evtest and/or ir-keytable -t to verify that what is popping up > looks correct for the buttons you're pressing. > > Yes, found evtest from Simon's post and will look inti ir-keytable. Just quickly, evtest gives: [root@family ~]# evtest /dev/input/event4 Input driver version is 1.0.0 Input device ID: bus 0x19 vendor 0x1050 product 0xa5 version 0x13 Input device name: "Nuvoton w836x7hg Infrared Remote Transceiver" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 28 (Enter) Event code 103 (Up) Event code 105 (Left) Event code 106 (Right) Event code 108 (Down) Event code 111 (Delete) Event code 113 (Mute) Event code 114 (VolumeDown) Event code 115 (VolumeUp) Event code 116 (Power) Event code 119 (Pause) Event code 125 (LeftMeta) Event code 128 (Stop) Event code 161 (EjectCD) Event code 164 (PlayPause) Event code 167 (Record) Event code 168 (Rewind) Event code 174 (Exit) Event code 207 (Play) Event code 208 (Fast Forward) Event code 210 (Print) Event code 212 (Camera) Event code 224 (Brightness down) Event code 225 (Brightness up) Event code 226 (Media) Event code 352 (Ok) Event code 356 (Power2) Event code 358 (Info) Event code 365 (EPG) Event code 366 (PVR) Event code 368 (Language) Event code 369 (Title) Event code 370 (Subtitle) Event code 372 (Zoom) Event code 373 (Mode) Event code 377 (TV) Event code 385 (Radio) Event code 386 (Tuner) Event code 389 (DVD) Event code 392 (Audio) Event code 393 (Video) Event code 398 (Red) Event code 399 (Green) Event code 400 (Yellow) Event code 401 (Blue) Event code 402 (ChannelUp) Event code 403 (ChannelDown) Event code 407 (Next) Event code 412 (Previous) Event code 425 (Presentation) Event code 512 (Numeric 0) Event code 513 (Numeric 1) Event code 514 (Numeric 2) Event code 515 (Numeric 3) Event code 516 (Numeric 4) Event code 517 (Numeric 5) Event code 518 (Numeric 6) Event code 519 (Numeric 7) Event code 520 (Numeric 8) Event code 521 (Numeric 9) Event code 522 (Numeric *) Event code 523 (Numeric #) Event type 4 (Misc) Event code 4 (ScanCode) Event type 20 (Repeat) Testing ... (interrupt to exit) Event: time 1302615722.494468, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302615722.939274, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302615723.459636, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302615723.974074, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302615724.483822, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302615725.000964, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302615725.509521, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302615726.018311, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302615726.563719, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302615727.076070, type 4 (Misc), code 4 (ScanCode), value 313 Event: time 1302616370.477735, type 4 (Misc), code 4 (ScanCode), value fc19 Event: time 1302616371.224748, type 4 (Misc), code 4 (ScanCode), value fc18 Event: time 1302616372.150460, type 4 (Misc), code 4 (ScanCode), value fc1b Event: time 1302616373.077919, type 4 (Misc), code 4 (ScanCode), value fc1a Event: time 1302616373.223535, type 4 (Misc), code 4 (ScanCode), value fc1a Event: time 1302616373.905272, type 4 (Misc), code 4 (ScanCode), value fc58 Event: time 1302616374.849790, type 4 (Misc), code 4 (ScanCode), value fc59 Event: time 1302616375.822604, type 4 (Misc), code 4 (ScanCode), value fc15 Event: time 1302616376.592487, type 4 (Misc), code 4 (ScanCode), value fc14 Event: time 1302616377.489575, type 4 (Misc), code 4 (ScanCode), value fc17 Event: time 1302616378.424942, type 4 (Misc), code 4 (ScanCode), value fc55 Event: time 1302616411.064600, type 4 (Misc), code 4 (ScanCode), value 10b Event: time 1302616411.743273, type 4 (Misc), code 4 (ScanCode), value 117 Event: time 1302616412.636573, type 4 (Misc), code 4 (ScanCode), value 11b Event: time 1302616413.689047, type 4 (Misc), code 4 (ScanCode), value 107 Event: time 1302637945.939532, type 4 (Misc), code 4 (ScanCode), value 10060 Event: time 1302637946.020771, type 4 (Misc), code 4 (ScanCode), value 10060 Event: time 1302637946.078128, type 4 (Misc), code 4 (ScanCode), value 10060 Event: time 1302637946.118720, type 4 (Misc), code 4 (ScanCode), value 10060 Event: time 1302637946.157547, type 4 (Misc), code 4 (ScanCode), value 10060 Event: time 1302637949.402311, type 4 (Misc), code 4 (ScanCode), value 10074 Event: time 1302637950.016715, type 4 (Misc), code 4 (ScanCode), value 10074 Event: time 1302637950.117775, type 4 (Misc), code 4 (ScanCode), value 10074 Event: time 1302637950.779558, type 4 (Misc), code 4 (ScanCode), value 10074 Event: time 1302637950.820186, type 4 (Misc), code 4 (ScanCode), value 10074 Event: time 1302637952.129569, type 4 (Misc), code 4 (ScanCode), value 10065 Event: time 1302637952.170202, type 4 (Misc), code 4 (ScanCode), value 10065 Event: time 1302637952.211408, type 4 (Misc), code 4 (ScanCode), value 10065 Event: time 1302639174.418040, type 4 (Misc), code 4 (ScanCode), value 10015 Event: time 1302639174.511809, type 4 (Misc), code 4 (ScanCode), value 10015 Event: time 1302641536.725852, type 4 (Misc), code 4 (ScanCode), value 10015 for three different remotes. >> and /dev/lirc0 and >> in mode2 and *something* is happening in irrecord, but nothing on irw yet. > Does irw work if you just drop the pre-existing mceusb config in place? > I'll have to have a look at that. >> This same remote looks remarkably different through the AF9015 and the >> nuvoton and eHome but remarkably similar through the eHome and nuvoton. >> Just an observation. > I'm not familiar with the AF9015 hardware, but I did try to make the > nuvoton-cir driver to behave as close as possible to the mceusb driver, > using the same sample period and very similar buffer parsing routines. > |
From: Jarod W. <ja...@wi...> - 2011-04-13 19:08:00
|
On Apr 12, 2011, at 5:23 PM, Douglas Clowes wrote: > On 2011-04-13 02:12, Jarod Wilson wrote: >> On Apr 12, 2011, at 9:18 AM, Douglas Clowes wrote: >> >>> On 2011-04-11 23:53, Douglas Clowes wrote: >>>> Wrote a little program to set the top two bits of CR 0x2C to "10" and >>>> interrupts all over the place. Seems the CIR pins (75 and 76) have to be >>>> enabled on this chip. Looks like that could belong in nvt_cir_ldev_init >>>> where you do the output pin selection. >>> I have added that code to the driver and it's looking good. >> Very cool. I overlooked some CIR bring-up stuff in the 667 doc I've >> got, it does indeed show a default value of 0x0a for CR 0x2c, and >> a need to set bits 7 and 6 to 1 and 0 respectively to enable CIR. >> >> The same register twiddles nothing but fan outputs on the 677, and >> its default value if 0xfc. By this point in the code though, we have >> the chip_major saved, so we can just conditionally or in 0x80 to >> that register, and I think we should be all good here. Something like >> this would presumably work: >> >> http://people.redhat.com/jwilson/misc/nvt-w83667hg-enable-cir.patch >> >> (With of course the removal of the chip id restriction in nvt_hw_detect). >> >> > I don't think that register 0x27 (CR_OUTPUT_PIN_SEL) does the same thing on the 667 and 677. Indeed, register 0x2c on the 667 seems to have the bits that are in register 0x27 on the 677. Assuming that there will be others and that they will be different Yeah, I think that's a better approach. We've got a bit of disjoint here, as I've posted stuff over on linux-media for review, but forgot to cc you on it. I'll get a patch that is similar to yours posted there with you on the cc list shortly. There are some additional complications from adding support for another newer Nuvoton chip variant. :) > The code for filtering short pulses is a hack at the moment, so ignore that, but there it is. Okay, that's more or less what I assumed you'd meant. ... >>> Speaking of irrecord, it doesn't seem to like the stream, even after >>> filtering sub-200uS pulses. >> Out of curiosity, are you filtering them driver-side? I wonder if there >> is an additional trigger level config register options somewhere that >> we need to set that would filter those out... >> >> > There is the fifo value 0x00 for glitch pulse but I'm not seeing any of those, possibly because I haven't explicitly looked for them. > > You may also notice that register base+0xF is IRFSM and read-only. It is writable as IR Minimum length register. I did have a poke at that and was set the GH bit in register IRSTS. Presumably I could also get an interrupt. After that bit came on, it didn't seem to go off until power-cycled so I'm not actively pursuing that avenue at the moment. I'll have to read up, my memory is a bit hazy in this area. >>> Can't learn, can't handle repeats. Works >>> much more better on the Philips eHome although the pulse train is >>> remarkably similar. Major difference, from what I can see, is that the >>> eHome has a leading 100000 space and trailing 600 pulse: >>> space 100000 >>> pulse 9000 >>> space 4350 >>> pulse 650 >>> space 1600 >>> pulse 600 >>> space 1600 >>> ... >>> pulse 650 >>> space 1600 >>> pulse 600 >>> space 39550 >>> pulse 8950 >>> space 2200 >>> pulse 600 >>> whilst the nuvoton has a leading 9000 pulse and a trailing long space: >>> pulse 9000 >>> space 4450 >>> pulse 600 >>> space 1600 >>> pulse 600 >>> space 1650 >>> ... >>> pulse 600 >>> space 1600 >>> pulse 600 >>> space 39700 >>> pulse 9000 >>> space 2200 >>> pulse 600 >>> space 95650 >>> pulse 9000 >>> space 2200 >>> pulse 600 >>> space 95250 >>> with the 9000/2200 pair being the repeat codes in both cases. >>> >>> Curious! >> Crap. One or the other of them is delivering the long space at the >> wrong time... I need to sort that out in my head, and get them >> behaving the same way there. Otherwise, the pulse trains do look >> more or less identical now. >> >> > I was thinking of doing something in the loop to both filter short transitions and merge the codes, instead of just looking at the low seven bits. So if this byte is the same type as last byte (pulse/space), just add duration else if long enough then send previous and change else just drop it. ir_raw_event_store_with_filter() already does at least the back to back samples of the same type merging. I have vague recollections of looking at using it in nuvoton-cir, but deciding against using it over just plain ir_raw_event_store(). The _with_filter variant is used by the mceusb and streamzap drivers though. > Prime this at the beginning with the long space which will get sent if there's a decent pulse at the start. If we get the 0x80 at the end and the saved duration is a space, just drop it. Something like that. There's a timeout reporting infrastructure that I think we may need to tie into, which might handle this automagically for us. Its actually used in ir_raw_event_store_with_filter(). Both mceusb and streamzap set a timeout value, nuvoton-cir currently does not. It probably should. (In fact, there's a related section of code #if 0'd out atm). ... >> Can use evtest and/or ir-keytable -t to verify that what is popping up >> looks correct for the buttons you're pressing. >> >> > Yes, found evtest from Simon's post and will look inti ir-keytable. Just quickly, evtest gives: > > [root@family ~]# evtest /dev/input/event4 > Input driver version is 1.0.0 > Input device ID: bus 0x19 vendor 0x1050 product 0xa5 version 0x13 > Input device name: "Nuvoton w836x7hg Infrared Remote Transceiver" > Supported events: ... > Event code 523 (Numeric #) > Event type 4 (Misc) > Event code 4 (ScanCode) > Event type 20 (Repeat) > Testing ... (interrupt to exit) > Event: time 1302615722.494468, type 4 (Misc), code 4 (ScanCode), value 313 > Event: time 1302615726.018311, type 4 (Misc), code 4 (ScanCode), value 313 > Event: time 1302615726.563719, type 4 (Misc), code 4 (ScanCode), value 313 > Event: time 1302615727.076070, type 4 (Misc), code 4 (ScanCode), value 313 > Event: time 1302616370.477735, type 4 (Misc), code 4 (ScanCode), value fc19 > Event: time 1302616371.224748, type 4 (Misc), code 4 (ScanCode), value fc18 > Event: time 1302616372.150460, type 4 (Misc), code 4 (ScanCode), value fc1b > Event: time 1302616373.077919, type 4 (Misc), code 4 (ScanCode), value fc1a > Event: time 1302616373.223535, type 4 (Misc), code 4 (ScanCode), value fc1a > Event: time 1302616373.905272, type 4 (Misc), code 4 (ScanCode), value fc58 > Event: time 1302616374.849790, type 4 (Misc), code 4 (ScanCode), value fc59 > Event: time 1302616375.822604, type 4 (Misc), code 4 (ScanCode), value fc15 > Event: time 1302616376.592487, type 4 (Misc), code 4 (ScanCode), value fc14 > Event: time 1302616377.489575, type 4 (Misc), code 4 (ScanCode), value fc17 > Event: time 1302616378.424942, type 4 (Misc), code 4 (ScanCode), value fc55 > Event: time 1302616411.064600, type 4 (Misc), code 4 (ScanCode), value 10b > Event: time 1302616411.743273, type 4 (Misc), code 4 (ScanCode), value 117 > Event: time 1302616412.636573, type 4 (Misc), code 4 (ScanCode), value 11b > Event: time 1302616413.689047, type 4 (Misc), code 4 (ScanCode), value 107 > Event: time 1302637945.939532, type 4 (Misc), code 4 (ScanCode), value 10060 > Event: time 1302637946.157547, type 4 (Misc), code 4 (ScanCode), value 10060 > Event: time 1302637949.402311, type 4 (Misc), code 4 (ScanCode), value 10074 > Event: time 1302637950.820186, type 4 (Misc), code 4 (ScanCode), value 10074 > Event: time 1302637952.129569, type 4 (Misc), code 4 (ScanCode), value 10065 > Event: time 1302639174.418040, type 4 (Misc), code 4 (ScanCode), value 10015 > > for three different remotes. None of which was the stock media center rc6 remote, I take it. -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-14 13:17:08
|
On 2011-04-14 05:07, Jarod Wilson wrote: > On Apr 12, 2011, at 5:23 PM, Douglas Clowes wrote: > >> On 2011-04-13 02:12, Jarod Wilson wrote: >>> On Apr 12, 2011, at 9:18 AM, Douglas Clowes wrote: >>> >>>> On 2011-04-11 23:53, Douglas Clowes wrote: >>>>> Wrote a little program to set the top two bits of CR 0x2C to "10" and >>>>> interrupts all over the place. Seems the CIR pins (75 and 76) have to be >>>>> enabled on this chip. Looks like that could belong in nvt_cir_ldev_init >>>>> where you do the output pin selection. >>>> I have added that code to the driver and it's looking good. >>> Very cool. I overlooked some CIR bring-up stuff in the 667 doc I've >>> got, it does indeed show a default value of 0x0a for CR 0x2c, and >>> a need to set bits 7 and 6 to 1 and 0 respectively to enable CIR. >>> >>> The same register twiddles nothing but fan outputs on the 677, and >>> its default value if 0xfc. By this point in the code though, we have >>> the chip_major saved, so we can just conditionally or in 0x80 to >>> that register, and I think we should be all good here. Something like >>> this would presumably work: >>> >>> http://people.redhat.com/jwilson/misc/nvt-w83667hg-enable-cir.patch >>> >>> (With of course the removal of the chip id restriction in nvt_hw_detect). >>> >>> >> I don't think that register 0x27 (CR_OUTPUT_PIN_SEL) does the same thing on the 667 and 677. Indeed, register 0x2c on the 667 seems to have the bits that are in register 0x27 on the 677. Assuming that there will be others and that they will be different > Yeah, I think that's a better approach. We've got a bit of disjoint here, > as I've posted stuff over on linux-media for review, but forgot to cc you > on it. I'll get a patch that is similar to yours posted there with you on > the cc list shortly. There are some additional complications from adding > support for another newer Nuvoton chip variant. :) > >> The code for filtering short pulses is a hack at the moment, so ignore that, but there it is. > Okay, that's more or less what I assumed you'd meant. > > ... >>>> Speaking of irrecord, it doesn't seem to like the stream, even after >>>> filtering sub-200uS pulses. >>> Out of curiosity, are you filtering them driver-side? I wonder if there >>> is an additional trigger level config register options somewhere that >>> we need to set that would filter those out... >>> >>> >> There is the fifo value 0x00 for glitch pulse but I'm not seeing any of those, possibly because I haven't explicitly looked for them. >> >> You may also notice that register base+0xF is IRFSM and read-only. It is writable as IR Minimum length register. I did have a poke at that and was set the GH bit in register IRSTS. Presumably I could also get an interrupt. After that bit came on, it didn't seem to go off until power-cycled so I'm not actively pursuing that avenue at the moment. > I'll have to read up, my memory is a bit hazy in this area. > > >>>> Can't learn, can't handle repeats. Works >>>> much more better on the Philips eHome although the pulse train is >>>> remarkably similar. Major difference, from what I can see, is that the >>>> eHome has a leading 100000 space and trailing 600 pulse: >>>> space 100000 >>>> pulse 9000 >>>> space 4350 >>>> pulse 650 >>>> space 1600 >>>> pulse 600 >>>> space 1600 >>>> ... >>>> pulse 650 >>>> space 1600 >>>> pulse 600 >>>> space 39550 >>>> pulse 8950 >>>> space 2200 >>>> pulse 600 >>>> whilst the nuvoton has a leading 9000 pulse and a trailing long space: >>>> pulse 9000 >>>> space 4450 >>>> pulse 600 >>>> space 1600 >>>> pulse 600 >>>> space 1650 >>>> ... >>>> pulse 600 >>>> space 1600 >>>> pulse 600 >>>> space 39700 >>>> pulse 9000 >>>> space 2200 >>>> pulse 600 >>>> space 95650 >>>> pulse 9000 >>>> space 2200 >>>> pulse 600 >>>> space 95250 >>>> with the 9000/2200 pair being the repeat codes in both cases. >>>> >>>> Curious! >>> Crap. One or the other of them is delivering the long space at the >>> wrong time... I need to sort that out in my head, and get them >>> behaving the same way there. Otherwise, the pulse trains do look >>> more or less identical now. >>> >>> >> I was thinking of doing something in the loop to both filter short transitions and merge the codes, instead of just looking at the low seven bits. So if this byte is the same type as last byte (pulse/space), just add duration else if long enough then send previous and change else just drop it. > ir_raw_event_store_with_filter() already does at least the back to > back samples of the same type merging. I have vague recollections > of looking at using it in nuvoton-cir, but deciding against using it > over just plain ir_raw_event_store(). The _with_filter variant is > used by the mceusb and streamzap drivers though. > > >> Prime this at the beginning with the long space which will get sent if there's a decent pulse at the start. If we get the 0x80 at the end and the saved duration is a space, just drop it. Something like that. > There's a timeout reporting infrastructure that I think we may need to > tie into, which might handle this automagically for us. Its actually > used in ir_raw_event_store_with_filter(). Both mceusb and streamzap > set a timeout value, nuvoton-cir currently does not. It probably should. > (In fact, there's a related section of code #if 0'd out atm). > > ... >>> Can use evtest and/or ir-keytable -t to verify that what is popping up >>> looks correct for the buttons you're pressing. >>> >>> >> Yes, found evtest from Simon's post and will look inti ir-keytable. Just quickly, evtest gives: >> >> [root@family ~]# evtest /dev/input/event4 >> Input driver version is 1.0.0 >> Input device ID: bus 0x19 vendor 0x1050 product 0xa5 version 0x13 >> Input device name: "Nuvoton w836x7hg Infrared Remote Transceiver" >> Supported events: > ... >> Event code 523 (Numeric #) >> Event type 4 (Misc) >> Event code 4 (ScanCode) >> Event type 20 (Repeat) >> Testing ... (interrupt to exit) >> Event: time 1302615722.494468, type 4 (Misc), code 4 (ScanCode), value 313 >> Event: time 1302615726.018311, type 4 (Misc), code 4 (ScanCode), value 313 >> Event: time 1302615726.563719, type 4 (Misc), code 4 (ScanCode), value 313 >> Event: time 1302615727.076070, type 4 (Misc), code 4 (ScanCode), value 313 >> Event: time 1302616370.477735, type 4 (Misc), code 4 (ScanCode), value fc19 >> Event: time 1302616371.224748, type 4 (Misc), code 4 (ScanCode), value fc18 >> Event: time 1302616372.150460, type 4 (Misc), code 4 (ScanCode), value fc1b >> Event: time 1302616373.077919, type 4 (Misc), code 4 (ScanCode), value fc1a >> Event: time 1302616373.223535, type 4 (Misc), code 4 (ScanCode), value fc1a >> Event: time 1302616373.905272, type 4 (Misc), code 4 (ScanCode), value fc58 >> Event: time 1302616374.849790, type 4 (Misc), code 4 (ScanCode), value fc59 >> Event: time 1302616375.822604, type 4 (Misc), code 4 (ScanCode), value fc15 >> Event: time 1302616376.592487, type 4 (Misc), code 4 (ScanCode), value fc14 >> Event: time 1302616377.489575, type 4 (Misc), code 4 (ScanCode), value fc17 >> Event: time 1302616378.424942, type 4 (Misc), code 4 (ScanCode), value fc55 >> Event: time 1302616411.064600, type 4 (Misc), code 4 (ScanCode), value 10b >> Event: time 1302616411.743273, type 4 (Misc), code 4 (ScanCode), value 117 >> Event: time 1302616412.636573, type 4 (Misc), code 4 (ScanCode), value 11b >> Event: time 1302616413.689047, type 4 (Misc), code 4 (ScanCode), value 107 >> Event: time 1302637945.939532, type 4 (Misc), code 4 (ScanCode), value 10060 >> Event: time 1302637946.157547, type 4 (Misc), code 4 (ScanCode), value 10060 >> Event: time 1302637949.402311, type 4 (Misc), code 4 (ScanCode), value 10074 >> Event: time 1302637950.820186, type 4 (Misc), code 4 (ScanCode), value 10074 >> Event: time 1302637952.129569, type 4 (Misc), code 4 (ScanCode), value 10065 >> Event: time 1302639174.418040, type 4 (Misc), code 4 (ScanCode), value 10015 >> >> for three different remotes. > None of which was the stock media center rc6 remote, I take it. > > Those ScanCodes looked OK, and clean. Maybe filtering isn't needed. I'll take it out and try it. At the moment it all looks good. I've loaded the correct keytable for my remote (Leadtek Y04g0051) and set up delay and period for the repeats and it's working brilliantly. # ir-keytable -s rc4 -c -w /etc/rc_keymaps/leadtek_y04g0051 #ir-keytable --delay=500 --period=100 # ir-keytable Found /sys/class/rc/rc4/ (/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 = 100 ms Then fired up lircd to take events from event4 to /var/run/lirc/lircd as: # lircd -H devinput -d /dev/input/event4 /etc/lirc/lircd.conf.devinput Now irw give me the expected keys, ircat gives me the expected codes except that my lircrc file needs work. Best of all, for those keys that are mapped OK, MythTV does the expected action including repeats of scroll up/down. Beautiful. It's still not getting into by-id as: ]# ls -lR /dev/input /dev/input: total 0 drwxr-xr-x. 2 root root 100 Apr 12 14:19 by-id drwxr-xr-x. 2 root root 100 Apr 12 14:19 by-path crw-r-----. 1 root root 13, 64 Apr 12 14:19 event0 crw-r-----. 1 root root 13, 65 Apr 12 14:19 event1 crw-r-----. 1 root root 13, 66 Apr 12 14:19 event2 crw-r-----. 1 root root 13, 67 Apr 12 14:19 event3 crw-r-----. 1 root root 13, 68 Apr 12 17:24 event4 crw-r-----. 1 root root 13, 63 Apr 12 14:19 mice crw-r-----. 1 root root 13, 32 Apr 12 14:19 mouse0 /dev/input/by-id: total 0 lrwxrwxrwx. 1 root root 9 Apr 12 14:19 usb-Logitech_USB_Receiver-event-kbd -> ../event2 lrwxrwxrwx. 1 root root 9 Apr 12 14:19 usb-Logitech_USB_Receiver-event-mouse -> ../event3 lrwxrwxrwx. 1 root root 9 Apr 12 14:19 usb-Logitech_USB_Receiver-mouse -> ../mouse0 /dev/input/by-path: total 0 lrwxrwxrwx. 1 root root 9 Apr 12 14:19 pci-0000:00:1d.1-usb-0:1:1.0-event-kbd -> ../event2 lrwxrwxrwx. 1 root root 9 Apr 12 14:19 pci-0000:00:1d.1-usb-0:1:1.1-event-mouse -> ../event3 lrwxrwxrwx. 1 root root 9 Apr 12 14:19 pci-0000:00:1d.1-usb-0:1:1.1-mouse -> ../mouse0 but it is a working system now. I found a lot of old and misleading documentation and not much that is correct. Thanks very much Jarod. |
From: Jarod W. <ja...@wi...> - 2011-04-14 19:15:05
|
On Apr 14, 2011, at 9:15 AM, Douglas Clowes wrote: ... >>> Yes, found evtest from Simon's post and will look inti ir-keytable. Just quickly, evtest gives: >>> >>> [root@family ~]# evtest /dev/input/event4 >>> Input driver version is 1.0.0 >>> Input device ID: bus 0x19 vendor 0x1050 product 0xa5 version 0x13 >>> Input device name: "Nuvoton w836x7hg Infrared Remote Transceiver" >>> Supported events: >> ... >>> Event code 523 (Numeric #) >>> Event type 4 (Misc) >>> Event code 4 (ScanCode) >>> Event type 20 (Repeat) >>> Testing ... (interrupt to exit) >>> Event: time 1302615722.494468, type 4 (Misc), code 4 (ScanCode), value 313 >>> Event: time 1302615726.018311, type 4 (Misc), code 4 (ScanCode), value 313 >>> Event: time 1302615726.563719, type 4 (Misc), code 4 (ScanCode), value 313 >>> Event: time 1302615727.076070, type 4 (Misc), code 4 (ScanCode), value 313 >>> Event: time 1302616370.477735, type 4 (Misc), code 4 (ScanCode), value fc19 >>> Event: time 1302616371.224748, type 4 (Misc), code 4 (ScanCode), value fc18 >>> Event: time 1302616372.150460, type 4 (Misc), code 4 (ScanCode), value fc1b >>> Event: time 1302616373.077919, type 4 (Misc), code 4 (ScanCode), value fc1a >>> Event: time 1302616373.223535, type 4 (Misc), code 4 (ScanCode), value fc1a >>> Event: time 1302616373.905272, type 4 (Misc), code 4 (ScanCode), value fc58 >>> Event: time 1302616374.849790, type 4 (Misc), code 4 (ScanCode), value fc59 >>> Event: time 1302616375.822604, type 4 (Misc), code 4 (ScanCode), value fc15 >>> Event: time 1302616376.592487, type 4 (Misc), code 4 (ScanCode), value fc14 >>> Event: time 1302616377.489575, type 4 (Misc), code 4 (ScanCode), value fc17 >>> Event: time 1302616378.424942, type 4 (Misc), code 4 (ScanCode), value fc55 >>> Event: time 1302616411.064600, type 4 (Misc), code 4 (ScanCode), value 10b >>> Event: time 1302616411.743273, type 4 (Misc), code 4 (ScanCode), value 117 >>> Event: time 1302616412.636573, type 4 (Misc), code 4 (ScanCode), value 11b >>> Event: time 1302616413.689047, type 4 (Misc), code 4 (ScanCode), value 107 >>> Event: time 1302637945.939532, type 4 (Misc), code 4 (ScanCode), value 10060 >>> Event: time 1302637946.157547, type 4 (Misc), code 4 (ScanCode), value 10060 >>> Event: time 1302637949.402311, type 4 (Misc), code 4 (ScanCode), value 10074 >>> Event: time 1302637950.820186, type 4 (Misc), code 4 (ScanCode), value 10074 >>> Event: time 1302637952.129569, type 4 (Misc), code 4 (ScanCode), value 10065 >>> Event: time 1302639174.418040, type 4 (Misc), code 4 (ScanCode), value 10015 >>> >>> for three different remotes. >> None of which was the stock media center rc6 remote, I take it. >> >> > Those ScanCodes looked OK, and clean. Maybe filtering isn't needed. I'll take it out and try it. Yeah, the scancodes look fine, I was just commenting that none of them looked like the RC6 scancodes for the stock remote (its produces 32-bit scancodes, and you should also see key names in the output). > At the moment it all looks good. > > I've loaded the correct keytable for my remote (Leadtek Y04g0051) and set up delay and period for the repeats and it's working brilliantly. > # ir-keytable -s rc4 -c -w /etc/rc_keymaps/leadtek_y04g0051 > #ir-keytable --delay=500 --period=100 > # ir-keytable > Found /sys/class/rc/rc4/ (/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 = 100 ms > > Then fired up lircd to take events from event4 to /var/run/lirc/lircd as: > # lircd -H devinput -d /dev/input/event4 /etc/lirc/lircd.conf.devinput > > Now irw give me the expected keys, ircat gives me the expected codes except that my lircrc file needs work. > > Best of all, for those keys that are mapped OK, MythTV does the expected action including repeats of scroll up/down. Beautiful. Excellent news. I've also got feedback from some openelec users with the two patches I've posted on linux-media, which says that both the Asus S1-AT5NM10E (w83667hg) and the Xtreamer Ultra (new w83677hg chip) are working as expected. http://openelec.tv/forum/19-feature-suggestions/5386-feature-request-asus-s1-at5nm10e-infrared#5422 http://openelec.tv/forum/19-feature-suggestions/5213-drivers-for-xtreamer-ultra For those following along at home, here's the two patches added to the driver that those folks were testing: https://patchwork.kernel.org/patch/701811/ https://patchwork.kernel.org/patch/705581/ These will go into 2.6.40 at the latest. (Might be too late to push them into 2.6.39). > It's still not getting into by-id Hrm. There may be some bits missing in the driver that need to get added to wire those up. I can't recall if I've actually looked for the by-id bits with my own nuvoton-cir hardware (probably not). > I found a lot of old and misleading documentation and not much that is correct. Any of it anywhere that I can correct it? I'm hoping to get a major FAQ and/or HOWTO sort of thing posted up on lirc.org relatively soon... > Thanks very much Jarod. And thank you for all the excellent investigative work and testing. :) -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-20 13:52:52
|
On 2011-04-15 05:15, Jarod Wilson wrote: > > <snip> >> It's still not getting into by-id > Hrm. There may be some bits missing in the driver that need to get added > to wire those up. I can't recall if I've actually looked for the by-id > bits with my own nuvoton-cir hardware (probably not). > > Yes, I suspect it has something to do with the usb_make_path(ir->usbdev, ir->phys, sizeof(ir->phys)); and usb_to_input_id(ir->usbdev, &rc->input_id); that are in streamzap and mceusb but aren't in nuvoton-cir. I'm not even sure where they should go yet since both of those drivers have a static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir) type function that contain them. >> I found a lot of old and misleading documentation and not much that is correct. > Any of it anywhere that I can correct it? I'm hoping to get a major FAQ > and/or HOWTO sort of thing posted up on lirc.org relatively soon... > > >> Thanks very much Jarod. > And thank you for all the excellent investigative work and testing. :) > > I'm still looking at all this and still testing. More notes later I expect. Douglas |
From: Jarod W. <ja...@wi...> - 2011-04-20 15:29:25
|
On Apr 20, 2011, at 9:51 AM, Douglas Clowes wrote: > On 2011-04-15 05:15, Jarod Wilson wrote: >> >> <snip> >>> It's still not getting into by-id >> Hrm. There may be some bits missing in the driver that need to get added >> to wire those up. I can't recall if I've actually looked for the by-id >> bits with my own nuvoton-cir hardware (probably not). >> >> > Yes, I suspect it has something to do with the > usb_make_path(ir->usbdev, ir->phys, sizeof(ir->phys)); > and > usb_to_input_id(ir->usbdev, &rc->input_id); > > that are in streamzap and mceusb but aren't in nuvoton-cir. I'm not even sure where they should go yet since both of those drivers have a > static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir) > type function that contain them. Yeah, will have to look at some other non-usb drivers to see what they're doing to accomplish similar... >>> I found a lot of old and misleading documentation and not much that is correct. >> Any of it anywhere that I can correct it? I'm hoping to get a major FAQ >> and/or HOWTO sort of thing posted up on lirc.org relatively soon... >> >> >>> Thanks very much Jarod. >> And thank you for all the excellent investigative work and testing. :) >> >> > I'm still looking at all this and still testing. More notes later I expect. If you have a chance, please give this kernel build a spin: http://kojipkgs.fedoraproject.org/packages/kernel/2.6.38.3/17.fc15/ Its got the two patches I sent upstream included in it... -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-21 14:04:08
|
On 2011-04-21 01:29, Jarod Wilson wrote: > On Apr 20, 2011, at 9:51 AM, Douglas Clowes wrote: > >> On 2011-04-15 05:15, Jarod Wilson wrote: >>> <snip> >>>> It's still not getting into by-id >>> Hrm. There may be some bits missing in the driver that need to get added >>> to wire those up. I can't recall if I've actually looked for the by-id >>> bits with my own nuvoton-cir hardware (probably not). >>> >>> >> Yes, I suspect it has something to do with the >> usb_make_path(ir->usbdev, ir->phys, sizeof(ir->phys)); >> and >> usb_to_input_id(ir->usbdev,&rc->input_id); >> >> that are in streamzap and mceusb but aren't in nuvoton-cir. I'm not even sure where they should go yet since both of those drivers have a >> static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir) >> type function that contain them. > Yeah, will have to look at some other non-usb drivers to see what > they're doing to accomplish similar... > > >>>> I found a lot of old and misleading documentation and not much that is correct. >>> Any of it anywhere that I can correct it? I'm hoping to get a major FAQ >>> and/or HOWTO sort of thing posted up on lirc.org relatively soon... >>> >>> >>>> Thanks very much Jarod. >>> And thank you for all the excellent investigative work and testing. :) >>> >>> >> I'm still looking at all this and still testing. More notes later I expect. > If you have a chance, please give this kernel build a spin: > > http://kojipkgs.fedoraproject.org/packages/kernel/2.6.38.3/17.fc15/ > > Its got the two patches I sent upstream included in it... > OK, installed that and the nvidia akmod rebuild failed, so I went in without the GUI. From memory, I did modprobe -r nuvoton-cir modprobe nuvoton-cir and the screen was flooded with error messages, another modprobe -r nuvoton-cir just hung. This from the log: Apr 21 18:11:40 family kernel: [ 1622.652595] nuvoton-cir 00:0a: disabled Apr 21 18:11:47 family kernel: [ 1629.616633] Registered IR keymap rc-rc6-mce Apr 21 18:11:47 family kernel: [ 1629.617090] input: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc1/input6 Apr 21 18:11:47 family kernel: [ 1629.622478] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 Apr 21 18:11:47 family kernel: [ 1629.623014] IP: [<ffffffffa00e14bb>] show_protocols+0x47/0xee [rc_core] Apr 21 18:11:47 family kernel: [ 1629.623014] PGD 12703f067 PUD 129976067 PMD 0 Apr 21 18:11:47 family kernel: [ 1629.623014] Oops: 0000 [#1] SMP Apr 21 18:11:47 family kernel: [ 1629.623014] last sysfs file: /sys/devices/virtual/rc/rc1/protocols Apr 21 18:11:47 family kernel: [ 1629.623014] CPU 1 Apr 21 18:11:47 family kernel: [ 1629.623014] Modules linked in: nuvoton_cir(+) nouveau ttm drm_kms_helper drm i2c_algo_bit video nfs lockd fscache nfs_acl auth_rpcgss Apr 21 18:11:47 family kernel: [ 1629.626366] rc1: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc1 Apr 21 18:11:47 family kernel: [ 1629.626703] rc rc1: lirc_dev: driver ir-lirc-codec (nuvoton-cir) registered at minor = 0 Apr 21 18:11:47 family kernel: [ 1629.623014] sco bnep l2cap sunrpc ipv6 p4_clockmod freq_table speedstep_lib uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq ir_lirc_codec snd_seq_device lirc_dev arc4 ir_sony_decoder snd_pcm ir_jvc_decoder ath9k mac80211 ir_rc6_decoder ath9k_common ir_rc5_decoder ath9k_hw snd_timer snd ath i2c_i801 microcode i2c_core rc_rc6_mce ir_nec_decoder btusb r8169 asus_atk0110 iTCO_wdt rc_core iTCO_vendor_support soundcore cfg80211 bluetooth mii joydev xhci_hcd serio_raw snd_page_alloc rfkill firewire_ohci firewire_core crc_itu_t [last unloaded: nuvoton_cir] Apr 21 18:11:47 family kernel: [ 1629.623014] Apr 21 18:11:47 family kernel: [ 1629.623014] Pid: 3023, comm: ir-keytable Not tainted 2.6.38.3-17.fc15.x86_64 #1 ASUSTeK Computer INC S1-AT5NM10E/S1-AT5NM10E Apr 21 18:11:47 family kernel: [ 1629.623014] RIP: 0010:[<ffffffffa00e14bb>] [<ffffffffa00e14bb>] show_protocols+0x47/0xee [rc_core] Apr 21 18:11:47 family kernel: [ 1629.623014] RSP: 0018:ffff880136601e38 EFLAGS: 00010202 Apr 21 18:11:47 family kernel: [ 1629.623014] RAX: 0000000000000000 RBX: ffffffffa00e3960 RCX: ffffffffa00e1474 Apr 21 18:11:47 family kernel: [ 1629.623014] RDX: ffff8801365f4000 RSI: ffffffffa00e3960 RDI: ffff880134f3c400 Apr 21 18:11:47 family kernel: [ 1629.623014] RBP: ffff880136601e68 R08: 0000000000000000 R09: 00000000000161c8 Apr 21 18:11:47 family kernel: [ 1629.623014] R10: 0000000000000002 R11: 00000000000014b2 R12: ffff8801365f4000 Apr 21 18:11:47 family kernel: [ 1629.623014] R13: 0000000000001000 R14: ffff880133e29a40 R15: ffff880129bcbc30 Apr 21 18:11:47 family kernel: [ 1629.623014] FS: 00007f2e24d85720(0000) GS:ffff8800bfc80000(0000) knlGS:0000000000000000 Apr 21 18:11:47 family kernel: [ 1629.623014] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 21 18:11:47 family kernel: [ 1629.623014] CR2: 0000000000000050 CR3: 000000013660d000 CR4: 00000000000006e0 Apr 21 18:11:47 family kernel: [ 1629.623014] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Apr 21 18:11:47 family kernel: [ 1629.623014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Apr 21 18:11:47 family kernel: [ 1629.623014] Process ir-keytable (pid: 3023, threadinfo ffff880136600000, task ffff880133d72e40) Apr 21 18:11:47 family kernel: [ 1629.623014] Stack: Apr 21 18:11:47 family kernel: [ 1629.623014] 0000000000000002 ffffffffa00e3960 ffff880136601f58 0000000000001000 Apr 21 18:11:47 family kernel: [ 1629.623014] ffff880133e29a40 ffff880129bcbc30 ffff880136601e98 ffffffff812e393d Apr 21 18:11:47 family kernel: [ 1629.623014] ffff880136601e88 ffffffff810dbba2 ffff880136601e98 ffff880133e29a20 Apr 21 18:11:47 family kernel: [ 1629.623014] Call Trace: Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff812e393d>] dev_attr_show+0x27/0x4e Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff810dbba2>] ? __get_free_pages+0xe/0x4a Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff811794ff>] sysfs_read_file+0xb2/0x15d Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff81121981>] vfs_read+0xa9/0xf0 Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff81121a12>] sys_read+0x4a/0x6e Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b Apr 21 18:11:47 family kernel: [ 1629.623014] Code: 85 ff 49 89 d4 0f 84 ba 00 00 00 83 bf c0 02 00 00 00 75 10 4c 8b af 90 02 00 00 48 8b 9f c8 02 00 00 eb 13 48 8b 87 b0 02 00 00 <4c> 8b 68 50 e8 b3 15 00 00 48 89 c3 83 3d 92 27 00 00 00 7e 1b Apr 21 18:11:47 family kernel: [ 1629.623014] RIP [<ffffffffa00e14bb>] show_protocols+0x47/0xee [rc_core] Apr 21 18:11:47 family kernel: [ 1629.623014] RSP <ffff880136601e38> Apr 21 18:11:47 family kernel: [ 1629.623014] CR2: 0000000000000050 Apr 21 18:11:47 family kernel: [ 1629.650194] ---[ end trace fbf817503d0149e1 ]--- Apr 21 18:11:47 family udevd-work[1699]: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc1' unexpected exit with status 0x0009 Apr 21 18:11:47 family kernel: [ 1629.660062] nuvoton_cir: driver has been successfully loaded Apr 21 18:13:12 family abrt: Kerneloops: Reported 1 kernel oopses to Abrt Apr 21 18:13:12 family abrtd: Directory 'kerneloops-1303373592-1388-1' creation detected Apr 21 18:13:12 family abrtd: New crash /var/spool/abrt/kerneloops-1303373592-1388-1, processing Apr 21 18:13:12 family abrtd: Registered Action plugin 'RunApp' Apr 21 18:13:12 family abrtd: RunApp('/var/spool/abrt/kerneloops-1303373592-1388-1','test x"`cat component`" = x"xorg-x11-server-Xorg" && cp /var/log/Xorg.0.log .') a reboot and repeat produced much the same :( I was doing something with ir-keytable before reloading the module for a fresh start. I'm thinking that I might put the F15 beta up over the weekend and have a play, maybe put this OS in if it's not there already. Anything specific you'd like to see? Regards, Douglas |
From: Jarod W. <ja...@wi...> - 2011-04-21 15:52:45
|
On Apr 21, 2011, at 10:03 AM, Douglas Clowes wrote: > On 2011-04-21 01:29, Jarod Wilson wrote: >> On Apr 20, 2011, at 9:51 AM, Douglas Clowes wrote: >> >>> On 2011-04-15 05:15, Jarod Wilson wrote: >>>> <snip> >>>>> It's still not getting into by-id >>>> Hrm. There may be some bits missing in the driver that need to get added >>>> to wire those up. I can't recall if I've actually looked for the by-id >>>> bits with my own nuvoton-cir hardware (probably not). >>>> >>>> >>> Yes, I suspect it has something to do with the >>> usb_make_path(ir->usbdev, ir->phys, sizeof(ir->phys)); >>> and >>> usb_to_input_id(ir->usbdev,&rc->input_id); >>> >>> that are in streamzap and mceusb but aren't in nuvoton-cir. I'm not even sure where they should go yet since both of those drivers have a >>> static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir) >>> type function that contain them. >> Yeah, will have to look at some other non-usb drivers to see what >> they're doing to accomplish similar... >> >> >>>>> I found a lot of old and misleading documentation and not much that is correct. >>>> Any of it anywhere that I can correct it? I'm hoping to get a major FAQ >>>> and/or HOWTO sort of thing posted up on lirc.org relatively soon... >>>> >>>> >>>>> Thanks very much Jarod. >>>> And thank you for all the excellent investigative work and testing. :) >>>> >>>> >>> I'm still looking at all this and still testing. More notes later I expect. >> If you have a chance, please give this kernel build a spin: >> >> http://kojipkgs.fedoraproject.org/packages/kernel/2.6.38.3/17.fc15/ >> >> Its got the two patches I sent upstream included in it... >> > OK, installed that and the nvidia akmod rebuild failed, so I went in without the GUI. > > From memory, I did > modprobe -r nuvoton-cir > modprobe nuvoton-cir > and the screen was flooded with error messages, another modprobe -r nuvoton-cir just hung. > > This from the log: > Apr 21 18:11:40 family kernel: [ 1622.652595] nuvoton-cir 00:0a: disabled > Apr 21 18:11:47 family kernel: [ 1629.616633] Registered IR keymap rc-rc6-mce > Apr 21 18:11:47 family kernel: [ 1629.617090] input: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc1/input6 > Apr 21 18:11:47 family kernel: [ 1629.622478] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 > Apr 21 18:11:47 family kernel: [ 1629.623014] IP: [<ffffffffa00e14bb>] show_protocols+0x47/0xee [rc_core] > Apr 21 18:11:47 family kernel: [ 1629.623014] PGD 12703f067 PUD 129976067 PMD 0 > Apr 21 18:11:47 family kernel: [ 1629.623014] Oops: 0000 [#1] SMP > Apr 21 18:11:47 family kernel: [ 1629.623014] last sysfs file: /sys/devices/virtual/rc/rc1/protocols > Apr 21 18:11:47 family kernel: [ 1629.623014] CPU 1 > Apr 21 18:11:47 family kernel: [ 1629.623014] Modules linked in: nuvoton_cir(+) nouveau ttm drm_kms_helper drm i2c_algo_bit video nfs lockd fscache nfs_acl auth_rpcgss > Apr 21 18:11:47 family kernel: [ 1629.626366] rc1: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/virtual/rc/rc1 > Apr 21 18:11:47 family kernel: [ 1629.626703] rc rc1: lirc_dev: driver ir-lirc-codec (nuvoton-cir) registered at minor = 0 > Apr 21 18:11:47 family kernel: [ 1629.623014] sco bnep l2cap sunrpc ipv6 p4_clockmod freq_table speedstep_lib uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq ir_lirc_codec snd_seq_device lirc_dev arc4 ir_sony_decoder snd_pcm ir_jvc_decoder ath9k mac80211 ir_rc6_decoder ath9k_common ir_rc5_decoder ath9k_hw snd_timer snd ath i2c_i801 microcode i2c_core rc_rc6_mce ir_nec_decoder btusb r8169 asus_atk0110 iTCO_wdt rc_core iTCO_vendor_support soundcore cfg80211 bluetooth mii joydev xhci_hcd serio_raw snd_page_alloc rfkill firewire_ohci firewire_core crc_itu_t [last unloaded: nuvoton_cir] > Apr 21 18:11:47 family kernel: [ 1629.623014] > Apr 21 18:11:47 family kernel: [ 1629.623014] Pid: 3023, comm: ir-keytable Not tainted 2.6.38.3-17.fc15.x86_64 #1 ASUSTeK Computer INC S1-AT5NM10E/S1-AT5NM10E > Apr 21 18:11:47 family kernel: [ 1629.623014] RIP: 0010:[<ffffffffa00e14bb>] [<ffffffffa00e14bb>] show_protocols+0x47/0xee [rc_core] > Apr 21 18:11:47 family kernel: [ 1629.623014] RSP: 0018:ffff880136601e38 EFLAGS: 00010202 > Apr 21 18:11:47 family kernel: [ 1629.623014] RAX: 0000000000000000 RBX: ffffffffa00e3960 RCX: ffffffffa00e1474 > Apr 21 18:11:47 family kernel: [ 1629.623014] RDX: ffff8801365f4000 RSI: ffffffffa00e3960 RDI: ffff880134f3c400 > Apr 21 18:11:47 family kernel: [ 1629.623014] RBP: ffff880136601e68 R08: 0000000000000000 R09: 00000000000161c8 > Apr 21 18:11:47 family kernel: [ 1629.623014] R10: 0000000000000002 R11: 00000000000014b2 R12: ffff8801365f4000 > Apr 21 18:11:47 family kernel: [ 1629.623014] R13: 0000000000001000 R14: ffff880133e29a40 R15: ffff880129bcbc30 > Apr 21 18:11:47 family kernel: [ 1629.623014] FS: 00007f2e24d85720(0000) GS:ffff8800bfc80000(0000) knlGS:0000000000000000 > Apr 21 18:11:47 family kernel: [ 1629.623014] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > Apr 21 18:11:47 family kernel: [ 1629.623014] CR2: 0000000000000050 CR3: 000000013660d000 CR4: 00000000000006e0 > Apr 21 18:11:47 family kernel: [ 1629.623014] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > Apr 21 18:11:47 family kernel: [ 1629.623014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Apr 21 18:11:47 family kernel: [ 1629.623014] Process ir-keytable (pid: 3023, threadinfo ffff880136600000, task ffff880133d72e40) > Apr 21 18:11:47 family kernel: [ 1629.623014] Stack: > Apr 21 18:11:47 family kernel: [ 1629.623014] 0000000000000002 ffffffffa00e3960 ffff880136601f58 0000000000001000 > Apr 21 18:11:47 family kernel: [ 1629.623014] ffff880133e29a40 ffff880129bcbc30 ffff880136601e98 ffffffff812e393d > Apr 21 18:11:47 family kernel: [ 1629.623014] ffff880136601e88 ffffffff810dbba2 ffff880136601e98 ffff880133e29a20 > Apr 21 18:11:47 family kernel: [ 1629.623014] Call Trace: > Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff812e393d>] dev_attr_show+0x27/0x4e > Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff810dbba2>] ? __get_free_pages+0xe/0x4a > Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff811794ff>] sysfs_read_file+0xb2/0x15d > Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff81121981>] vfs_read+0xa9/0xf0 > Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff81121a12>] sys_read+0x4a/0x6e > Apr 21 18:11:47 family kernel: [ 1629.623014] [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b > Apr 21 18:11:47 family kernel: [ 1629.623014] Code: 85 ff 49 89 d4 0f 84 ba 00 00 00 83 bf c0 02 00 00 00 75 10 4c 8b af 90 02 00 00 48 8b 9f c8 02 00 00 eb 13 48 8b 87 b0 02 00 00 <4c> 8b 68 50 e8 b3 15 00 00 48 89 c3 83 3d 92 27 00 00 00 7e 1b > Apr 21 18:11:47 family kernel: [ 1629.623014] RIP [<ffffffffa00e14bb>] show_protocols+0x47/0xee [rc_core] > Apr 21 18:11:47 family kernel: [ 1629.623014] RSP <ffff880136601e38> > Apr 21 18:11:47 family kernel: [ 1629.623014] CR2: 0000000000000050 > Apr 21 18:11:47 family kernel: [ 1629.650194] ---[ end trace fbf817503d0149e1 ]--- > Apr 21 18:11:47 family udevd-work[1699]: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc1' unexpected exit with status 0x0009 > Apr 21 18:11:47 family kernel: [ 1629.660062] nuvoton_cir: driver has been successfully loaded > Apr 21 18:13:12 family abrt: Kerneloops: Reported 1 kernel oopses to Abrt > Apr 21 18:13:12 family abrtd: Directory 'kerneloops-1303373592-1388-1' creation detected > Apr 21 18:13:12 family abrtd: New crash /var/spool/abrt/kerneloops-1303373592-1388-1, processing > Apr 21 18:13:12 family abrtd: Registered Action plugin 'RunApp' > Apr 21 18:13:12 family abrtd: RunApp('/var/spool/abrt/kerneloops-1303373592-1388-1','test x"`cat component`" = x"xorg-x11-server-Xorg" && cp /var/log/Xorg.0.log .') > > a reboot and repeat produced much the same :( Aieeee! > I was doing something with ir-keytable before reloading the module for a fresh start. > > I'm thinking that I might put the F15 beta up over the weekend and have a play, maybe put this OS in if it's not there already. > > Anything specific you'd like to see? Does it behave less badly if you disable the ir-keytable udev rule? I've got an almost identical nuvoton-cir running on my asrock box w/o a problem, but its a 2.6.32-based kernel, and no udev rules. Looks like I may need to throw Fedora 15 on this system... -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-22 13:44:10
|
On 2011-04-22 01:52, Jarod Wilson wrote: > <snip> >> a reboot and repeat produced much the same :( > Aieeee! > Installed F15 Beta and the chipset is not recognised - as expected. Installed your kernel and it works (up to a point). It recognises the chipset, installs the keytable that doesn't work with my remote but shows the scancodes. After installing my keytable it show keycodes but lircd was not pumping them through to irw. I managed to get the codes out of irw when I ran lircd by hand even though it was just a cut and paste from "ps -ef | grep lirc" but I saw that on F14 as well. It's like it doesn't like the --device=name=Nuvoton?... in init.d. I reloaded it with modprobe and no errors. >> I was doing something with ir-keytable before reloading the module for a fresh start. >> >> I'm thinking that I might put the F15 beta up over the weekend and have a play, maybe put this OS in if it's not there already. >> >> Anything specific you'd like to see? > Does it behave less badly if you disable the ir-keytable udev rule? > > I've got an almost identical nuvoton-cir running on my asrock box w/o > a problem, but its a 2.6.32-based kernel, and no udev rules. Looks like > I may need to throw Fedora 15 on this system... > Bottom line, the nuvoton-cir works fine, now if only the keytables were correct :) Cheers, Douglas |
From: Jarod W. <ja...@wi...> - 2011-04-25 15:12:04
|
On Apr 22, 2011, at 9:43 AM, Douglas Clowes wrote: > On 2011-04-22 01:52, Jarod Wilson wrote: >> <snip> >>> a reboot and repeat produced much the same :( >> Aieeee! >> > Installed F15 Beta and the chipset is not recognised - as expected. Installed your kernel and it works (up to a point). > > It recognises the chipset, installs the keytable that doesn't work with my remote but shows the scancodes. > > After installing my keytable it show keycodes but lircd was not pumping them through to irw. > > I managed to get the codes out of irw when I ran lircd by hand even though it was just a cut and paste from "ps -ef | grep lirc" but I saw that on F14 as well. It's like it doesn't like the --device=name=Nuvoton?... in init.d. Hrm. Probably some 'fun with escaping shell variables' necessary there, only idea I've got. > I reloaded it with modprobe and no errors. >>> I was doing something with ir-keytable before reloading the module for a fresh start. >>> >>> I'm thinking that I might put the F15 beta up over the weekend and have a play, maybe put this OS in if it's not there already. >>> >>> Anything specific you'd like to see? >> Does it behave less badly if you disable the ir-keytable udev rule? >> >> I've got an almost identical nuvoton-cir running on my asrock box w/o >> a problem, but its a 2.6.32-based kernel, and no udev rules. Looks like >> I may need to throw Fedora 15 on this system... >> > Bottom line, the nuvoton-cir works fine, now if only the keytables were correct :) This is the Leadtek remote you're talking about here, right? And if I understand correctly, its not a remote that was bundled with the system, and thus not one that can be auto-configured by the driver. A rule can be added to /etc/rc_maps.cfg to auto-load it though. -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-27 13:26:59
|
On 2011-04-26 01:12, Jarod Wilson wrote: > <snip> > This is the Leadtek remote you're talking about here, right? And if > I understand correctly, its not a remote that was bundled with the > system, and thus not one that can be auto-configured by the driver. > A rule can be added to /etc/rc_maps.cfg to auto-load it though. > Yes, I have two Leadtek remotes. They seem to generate mostly the same codes but are interpreted differently on the two systems. The Y04G0033 is the older one and has the "Leadtek", "Winfast" and "CoolCommand" branding. The other is the Y04G0051 which only has the "Leadtek" branding. They came variously with the DTV1000-T, DTV2000-H and Dongle Gold. Using the Y04G0051 with the DTV1000-T requires using keytable "/etc/rc_keymaps/winfast" while using the exact same remote with the nuvoton-cir requires using keytable "/etc/rc_keymaps/leadtek_y04g0051". It would be nice if the same key did the same thing on both machines (and others). The most obvious failing is that the left and right keys are transposed in the winfast keytable :) while the other discrepancies are more subtle. Douglas |
From: Jarod W. <ja...@wi...> - 2011-04-27 18:36:04
|
On Apr 27, 2011, at 9:25 AM, Douglas Clowes wrote: > On 2011-04-26 01:12, Jarod Wilson wrote: >> <snip> >> This is the Leadtek remote you're talking about here, right? And if >> I understand correctly, its not a remote that was bundled with the >> system, and thus not one that can be auto-configured by the driver. >> A rule can be added to /etc/rc_maps.cfg to auto-load it though. >> > Yes, I have two Leadtek remotes. They seem to generate mostly the same codes but are interpreted differently on the two systems. The Y04G0033 is the older one and has the "Leadtek", "Winfast" and "CoolCommand" branding. The other is the Y04G0051 which only has the "Leadtek" branding. They came variously with the DTV1000-T, DTV2000-H and Dongle Gold. > > Using the Y04G0051 with the DTV1000-T requires using keytable "/etc/rc_keymaps/winfast" while using the exact same remote with the nuvoton-cir requires using keytable "/etc/rc_keymaps/leadtek_y04g0051". It would be nice if the same key did the same thing on both machines (and others). Looking at the two keytables side by side, it looks like the winfast one is used for receivers that strip out all but the bare minimum button code, while the leadtek one has full NEC scancodes. This is a fun little problem with many embedded IR decoders, which think they know better than you do, and don't give you all the decoded data. In some cases, its actually the device driver gobbling up the data, but not all. Don't know specifically about this one. > The most obvious failing is that the left and right keys are transposed in the winfast keytable :) while the other discrepancies are more subtle. Patches welcomed! :) I'd say make those two the same, since they really are for the same signals, one just uses a less complete scancode for lookup, due to driver or hardware limitations. Nb: I believe all the keymaps in v4l-utils are generated dynamically from the keymaps inside the kernel, so patches should really be against the keymaps in drivers/media/rc/keymaps/ in the kernel. -- Jarod Wilson ja...@wi... |
From: Douglas C. <dcl...@op...> - 2011-04-07 14:18:14
|
On 2011-04-07 00:35, Jarod Wilson wrote: > On Apr 5, 2011, at 6:26 PM, Douglas Clowes wrote: > >> Hi Jarod, >> >> I too have the ASUS barebones with this hardware, so I am also >> interested in this solution. >> >> I am running a MythTV frontend on Fedora 14. I have tried (and so far >> failed) to build the drivers, with a view to participating in this effort. >> >> I have also downloaded the kernel source and built it. While there are >> no errors, there are over 200 warnings which I have yet to review. >> >> I expect that I will patch that kernel and try to boot it. >> >> If there's something else you would like, let me know. If you want >> access to the box, it can be arranged although I am in UTC+10 so >> keypresses might be difficult. > I don't know that access without a way to deliver keypresses will be > of any use just yet, but its something I'll keep in mind. If you did > happen to have a transmitter laying about though, something could be > rigged up that could be used entirely remotely (pun not intended) > without an actual ... remote. :) (The fact its a system running Fedora > helps too, much more comfortable there than anywhere else, for obvious > reasons). > Hi Jarod, I asked Nuvoton for the W83667HG and W83677HG data sheets, they sent me the one for the 667 only. Looking at it briefly, it seems to be very different from the chip this driver is targeted at. For example, IR is on logical device 3 (UARTB), not 6 and logical device 0e is "reserved" (page46). The software example seems to show all operations between the 0x87s and 0xaa (page 48). Register 0xF1 seems to default to 0x00 which seems to have the IR function disabled and you don't seem to use that register at all. Could you shoot me the 677 data sheet please, if it's handy, so I can better understand the differences. Thanks, Douglas |
From: Jarod W. <ja...@wi...> - 2011-04-07 21:41:40
|
On Apr 7, 2011, at 10:17 AM, Douglas Clowes wrote: > On 2011-04-07 00:35, Jarod Wilson wrote: >> On Apr 5, 2011, at 6:26 PM, Douglas Clowes wrote: >> >>> Hi Jarod, >>> >>> I too have the ASUS barebones with this hardware, so I am also >>> interested in this solution. >>> >>> I am running a MythTV frontend on Fedora 14. I have tried (and so far >>> failed) to build the drivers, with a view to participating in this effort. >>> >>> I have also downloaded the kernel source and built it. While there are >>> no errors, there are over 200 warnings which I have yet to review. >>> >>> I expect that I will patch that kernel and try to boot it. >>> >>> If there's something else you would like, let me know. If you want >>> access to the box, it can be arranged although I am in UTC+10 so >>> keypresses might be difficult. >> I don't know that access without a way to deliver keypresses will be >> of any use just yet, but its something I'll keep in mind. If you did >> happen to have a transmitter laying about though, something could be >> rigged up that could be used entirely remotely (pun not intended) >> without an actual ... remote. :) (The fact its a system running Fedora >> helps too, much more comfortable there than anywhere else, for obvious >> reasons). >> > Hi Jarod, > > I asked Nuvoton for the W83667HG and W83677HG data sheets, they sent me the one for the 667 only. > > Looking at it briefly, it seems to be very different from the chip this driver is targeted at. For example, IR is on logical device 3 (UARTB), not 6 and logical device 0e is "reserved" (page46). You've either got a completely different W83667HG datasheet from the one I have, or, well, I have no other explanation. :) Section 7, CONFIGURATION REGISTER ACCESS PROTOCOL here, clearly states that logical device 3 is UARTB, and Consumer IR is on logical device 6, shared with Serial Peripheral Interface. This does differ from the 677, where logical device 6 is dedicated to CIR. Additionally, logical device E is clearly marked as being for CIR Wake-up in the sheet I'm looking at, same as the 677. Fwiw, the datasheet I've got is 311 pages long, with 28 sections to it, revision 1.3, dated 10/16/2008... > The software example seems to show all operations between the 0x87s and 0xaa (page 48). Register 0xF1 seems to default to 0x00 which seems to have the IR function disabled and you don't seem to use that register at all. > > Could you shoot me the 677 data sheet please, if it's handy, so I can better understand the differences. I can't, they were provided to me by Nuvoton with the caveat that I not pass them around at all. I could ask my contact if he can either send you copies directly or give me permission to send them to you though. (Reciprocally, you can send me what you've got, if you haven't been given any restriction on redistribution, and maybe something will make more sense putting it next to the 667 datasheet I've got). -- Jarod Wilson ja...@wi... |