Re: [linux-dvb] [patch] support for key repeat with dib0700 ir receiver
Wouldn't going away from an event interface kill a possible direct link between the remote and X? Yes, it would. The way I see it, LIRC is an additional layer that may be one too many in most cases. From my point of view, it is a relative pain I could do without. But I may have tunnel vision by lack of knowledge. I agree with you. I'm more looking for a solution with existing things. LIRC is not in kernel. I don't think we should do something specific, new. If there is nothing which can be done with the event system I think we should either extend it or just drop this idea. IMHO, the event interface does not match well with the reduced key set on a remote control. The keys are mapped in the driver which makes it difficult to customize. I'm not talking about the current problem with the mappings being hardcoded -- that could probably be solved without too much work. The problem I see with the mapping taking place in the driver, is that the interpretation of the key presses and releases should be application-specific. If I'm in MythTV, I want one interpretation. In Evolution, the same keypress should be interpreted differently. Firefox has a third set of mappings. Lircd solves this problem for me, while the event interface creates one static mapping. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Very quiet around Nova-T 500
The strange thing is that modinfo does not say anything about a level 15 debug for the dvb_usb_dib0700 module. http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500#dvb_usb_dib0700 The debug value is a bit field, with each bit representing a different category. With all bits on (ie full debugging) the decimal value becomes 15. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch] support for key repeat with dib0700 ir receiver
In any case, especially to that problem with unknown key code I think it is time to change the IR-behavior of the DVB-USB. My problem is, I don't know how. My naive idea would be, that the IR-code is reporting each key (as raw as possible) without mapping it to an event to the event interface and then someone, somewhere is interpreting it. Also forward any repeat-attribute. I would suggest creating a netlink device which lircd (or similar) can read from. I haven't really looked further into it since I never really intended on having the IR support from the DVB devices; my brewing mythtv frontend system is both diskless and tunerless so I have a USB MCE IR dongle instead. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Nova-T 500 issues - losing one tuner
Not too much comfort, but... Maybe a different problem, but the tuner is really lost until a reboot all the same. You don't need to reboot to regain the other tuner. I use the following: service mythbackend stop modprobe -r dvb_usb_dib0700 modprobe dvb_usb_dib0700 service mythbackend start After that, the tuner is back on line. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Nova-T 500 issues - losing one tuner
Hi all, I have a hunch about this problem... ... This, ... leads me to believe that this is timer-induced. Something can't keep up. Adding debugging makes the operations slightly slower (the module needs to do additional IO to speak to syslogd), and this delay seems to be enough to keep it operational. Attached is an extremely simple patch which seems to resolve the issue for me. Before turning streaming on/off, I have inserted a tiny delay or 10 ms- Just using 'debug=1' wasn't enough to keep tuner 2 from dying. I set it up yesterday morning with debug=1, and when I got back home in the evening the second tuner was dead again. I then made the attached patch and the system has been stable since then (~24 hrs). I also made a slight change by removing a | 0x00 from the code. It performs absolutely nothing (and is probably removed by the compiler in optimization) but confuse when reading the code, imho... Patrick, if you really want it there I can recreate the patch with the or statement back ;) Feel free to try it out. // J diff -r c08115f8f1f3 linux/drivers/media/dvb/dvb-usb/dib0700_core.c --- a/linux/drivers/media/dvb/dvb-usb/dib0700_core.c Sun Jan 27 17:24:26 2008 + +++ b/linux/drivers/media/dvb/dvb-usb/dib0700_core.c Mon Feb 04 19:17:03 2008 +0100 @@ -243,7 +243,7 @@ int dib0700_streaming_ctrl(struct dvb_us u8 b[4]; b[0] = REQUEST_ENABLE_VIDEO; - b[1] = (onoff 4) | 0x00; /* this bit gives a kind of command, rather than enabling something or not */ + b[1] = (onoff 4); /* this bit gives a kind of command, rather than enabling something or not */ b[2] = (0x01 4); /* Master mode */ b[3] = 0x00; @@ -256,6 +256,7 @@ int dib0700_streaming_ctrl(struct dvb_us b[2] |= st-channel_state; + msleep(10); deb_info(data for streaming: %x %x\n,b[1],b[2]); return dib0700_ctrl_wr(adap-dev, b, 4); ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Nova-T 500 issues - losing one tuner
Hmm... typical, isn't it? Just about ten minutes after I've sent out the patch, the second tuner died again. It appears this is *not* enough to fix the issue. Please discard the previous mail. // J On Mon, 2008-02-04 at 19:28 +0100, Jonas Anden wrote: Hi all, I have a hunch about this problem... ... This, ... leads me to believe that this is timer-induced. Something can't keep up. Adding debugging makes the operations slightly slower (the module needs to do additional IO to speak to syslogd), and this delay seems to be enough to keep it operational. Attached is an extremely simple patch which seems to resolve the issue for me. Before turning streaming on/off, I have inserted a tiny delay or 10 ms- Just using 'debug=1' wasn't enough to keep tuner 2 from dying. I set it up yesterday morning with debug=1, and when I got back home in the evening the second tuner was dead again. I then made the attached patch and the system has been stable since then (~24 hrs). I also made a slight change by removing a | 0x00 from the code. It performs absolutely nothing (and is probably removed by the compiler in optimization) but confuse when reading the code, imho... Patrick, if you really want it there I can recreate the patch with the or statement back ;) Feel free to try it out. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Nova-T 500 issues - losing one tuner
I have a hunch about this problem... I had this problem (I tink 3 times last weekend) after initially updating my hg tree and recompiling the modules. I then turned on full debugging for the dib0700 module in order to try to see what happens when it goes wrong, but with full debugging on I haven't been able to reproduce the problem. I ran with full debugging on from monday to saturday and *really* tried to make it go away. I tried starting all tuners at once (ie scheduling three programs with the same start time), I tried running long recordings, I tried running plenty of retuning, and I tried doing it my normal way of a few recordings a day. Nothing made the tuner die. So yesterday, I finally gave up in trying to cause the problem. I turned debugging back off, and this morning one of the tuners is dead again (MythTV stopping at L__ instead of proceeding to LMS.) The *ONLY* change I have made is changing the debugging setting. This, in combination with the fact that some people see it and some don't, leads me to believe that this is timer-induced. Something can't keep up. Adding debugging makes the operations slightly slower (the module needs to do additional IO to speak to syslogd), and this delay seems to be enough to keep it operational. I don't think this has anything to do with the remote since I have the RC feature disabled (I'm using an M$ MCE remote instead). I set it up with full debugging (options dvb_usb_0700 debug=15). This will cause a whole bunch of logging in the system logs, but appears to keep the tuner alive. I have now changed the debug setting to 1 (only 'info' type messages) to see if that also keeps the tuner alive. My system has a 3.3 Ghz Celeron processor. Shaun, Ben, Nicolas -- what kind of systems are you running? If my hunch is correct, I'd expect Shaun and Ben to have faster processors than Nicolas since they are seeing this issue and Nicolas isn't. // J On Sat, 2008-02-02 at 10:20 +, Shaun wrote: On Friday 01 February 2008 21:43:51 Nicolas Will wrote: On Fri, 2008-02-01 at 21:07 +, Ben Firshman wrote: Feb 1 20:52:04 mythtv kernel: [ 11.072000] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware Feb 1 20:52:04 mythtv kernel: [ 11.132000] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.10.fw' ... Feb 1 20:52:04 mythtv kernel: [ 11.844000] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. Feb 1 20:52:04 mythtv kernel: [ 11.844000] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Feb 1 20:52:04 mythtv kernel: [ 11.844000] DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) Feb 1 20:52:04 mythtv kernel: [ 11.956000] DVB: registering frontend 1 (DiBcom 3000MC/P)... ... Feb 1 20:52:04 mythtv kernel: [ 12.50] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Feb 1 20:52:04 mythtv kernel: [ 12.50] DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) Feb 1 20:52:04 mythtv kernel: [ 12.508000] DVB: registering frontend 2 (DiBcom 3000MC/P)... Feb 1 20:52:04 mythtv kernel: [ 13.068000] input: IR-receiver inside an USB DVB receiver as /class/input/input2 Feb 1 20:52:04 mythtv kernel: [ 13.068000] dvb-usb: schedule remote query interval to 150 msecs. Feb 1 20:52:04 mythtv kernel: [ 13.068000] dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. Got the tree from the day of your message, and I'm still having problems. I'm not the only one either: http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022629.html Thanks Ben Nicolas Will wrote: On Sun, 2008-01-27 at 14:30 +, Ben Firshman wrote: I am using the (almost) latest SVN version of mythtv. I am using the v4l-dvb sources from a couple of days back. I have followed and used the patches that were on (are they in the repos now?): http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500 After a short while, one of the tuners dies. I get a (L__) Partial Lock message from mythtv. If it's any help, I also get messages like: DVB: frontend 0 frequency limits undefined - fix the driver In syslog, but that's even when it's working fine. Weird issue that I never encountered since I started using the card in August... Get a brand new tree, there have been a lot of changes very recently, merge of old patches and new fixes too. Make sure that you have the right firmware too. Then do a cold reboot, going through a power down, then check in the messages that the card was found in a cold state before a firmware upload. http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500#Firmware Nico Ben, I'm at loss for an explanation. I'm just not experiencing your problem.
Re: [linux-dvb] PULL request for a bunch of DiBcom-based changes
I have just built and started using the new HG, the unknown code problem with the remote support in my stick flooding /var/log/messages was a pain, but that was solved by simply wrapping the sensors in LX tape to prevent it receiving codes ;) If you're not going to use the sensor, disable the RC polling by adding the following line to your modprobe.conf: options dvb_usb disable_rc_polling=1 That's a cleaner solution in my opinion. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] PULL request for a bunch of DiBcom-based changes
If you're not going to use the sensor, disable the RC polling by adding the following line to your modprobe.conf: options dvb_usb disable_rc_polling=1 That's a cleaner solution in my opinion. That one is for the wiki. Is there a place/file describing all those options? Not that I know of. I found it in the source code while looking at how to put a patch in to disable the polling. I found it was already possible ;) // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] PULL request for a bunch of DiBcom-based changes
On Wed, 2008-01-30 at 17:05 +0100, Patrick Boettcher wrote: On Wed, 30 Jan 2008, Jonas Anden wrote: If you're not going to use the sensor, disable the RC polling by adding the following line to your modprobe.conf: options dvb_usb disable_rc_polling=1 That's a cleaner solution in my opinion. That one is for the wiki. Is there a place/file describing all those options? Not that I know of. I found it in the source code while looking at how to put a patch in to disable the polling. I found it was already possible ;) modinfo dvb-usb modinfo dvb-usb-dib0700 Yeah, sure, you can get it from the compiled modules... I was referring to a more thorough documentation. To easily get all options available in your installation (affecting DVB): for m in `/sbin/lsmod | grep dvb | cut -d ' ' -f 1`; do echo $m:; /sbin/modinfo $m | grep '^parm:' | cut -b 17- | sed 's/:/\t\t/'; echo; done Sample output on my system, with a Nova-T 500 and a Nova-T Stick, after some manual reformatting: dvb_usb_dib0700: force_lna_activation force the activation of Low-Noise-Amplifyer(s) (LNA), if applicable for the device (default: 0=automatic/off). (int) debug set debugging level (1=info,2=fw,4=fwdata,8=data (or-able)). (int) dvb_usb_dib0700_ir_proto set ir protocol (0=NEC, 1=RC5 (default), 2=RC6). (int) dib7000p: = debug turn on debugging (default: 0) (int) buggy_sfn_workaround Enable work-around for buggy SFNs (default: 0) (int) dib7000m: = debug turn on debugging (default: 0) (int) dvb_usb: debug set debugging level (1=info,xfer=2,pll=4, ts=8,err=16,rc=32,fw=64,mem=128,uxfer=256 (or-able)). (int) disable_rc_pollingdisable remote control polling (default: 0). (int) force_pid_filter_usageforce all dvb-usb-devices to use a PID filter, if any (default: 0). (int) dvb_core: = dvb_net_debug enable debug messages (int) frontend_debugTurn on/off frontend core debugging (default:off). (int) dvb_shutdown_timeout wait shutdown_timeout seconds after close() before suspending hardware (int) dvb_force_auto_inversion 0: normal (default), 1: INVERSION_AUTO forced always (int) dvb_override_tune_delay 0: normal (default), 0 = delay in milliseconds to wait for lock after a tune attempt (int) dvb_powerdown_on_sleep0: do not power down, 1: turn LNB voltage off on sleep (default) (int) cam_debug enable verbose debug messages (int) debug Turn on/off debugging (default:off). (int) dvbdev_debug Turn on/off device debugging (default:off). (int) dib3000mc: == debug turn on debugging (default: 0) (int) buggy_sfn_workaround Enable work-around for buggy SFNs (default: 0) (int) dib0070: debug turn on debugging (default: 0) (int) // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Nova-TD Stick too sensitive?
I have a strange problem with my Nova-TD Stick (USB ID 2040:9580). A couple of months ago, I rebuilt my antenna setup and replaced all the cables, the amplifier and splitter by high-quality versions, and since then all the other cards (one Nova-T 500 and one Nova-T Stick) have gotten much improved signal quality. But for some reason, the Nova-TD Stick won't lock. MythTV claims 100% signal strength but doesn't achieve a lock. Since I really don't *need* the TD tuners (I got the TD before I got the simple T stick and before there was any hint of any Linux drivers for it, and three tuners really ought to be enough for anybody[tm]), I was content with leaving the TD stick unconnected. Yesterday, however, my system crashed again (due to i2c errors), and I went to work updating the box to the latest (F7) kernel, updated the hg tree and recompiled all the dvb drivers (haven't seen any i2c errors since then, btw -- Yay!). Just for the fun of it, I plugged in the TD stick to see if the situation had improved. It hadn't. I tested using the MythTV suggestions; use tzap -r to set it to streaming, and cat video.mpg. tzap claims it gets a lock, but I receive no data from the stick. The tzap output looks like this: # tzap -r -a 4 'TV6' using '/dev/dvb/adapter4/frontend0' and '/dev/dvb/adapter4/demux0' tuning to 64200 Hz video pid 0x0437, audio pid 0x0436 status 0a | signal | snr | ber 001f | unc | status 1a | signal | snr | ber 001f | unc | FE_HAS_LOCK status 1a | signal | snr | ber 001f | unc | FE_HAS_LOCK status 1a | signal | snr | ber 001f | unc | FE_HAS_LOCK status 1a | signal | snr | ber 001f | unc | FE_HAS_LOCK Being a bit careless, I accidentally left the cat and tzap running while unplugging the device from the amplifier. Lo and behold, the signal level dropped, and it started feeding data into the mpg file. Only temporarily while the cable was aimed in the wrong direction, but yet -- the dvr0 device actually generated data! Once I completely disconnected the signal cable, the signal dropped down to 0 (pretty much expected): # tzap -r -a 4 'TV6' using '/dev/dvb/adapter4/frontend0' and '/dev/dvb/adapter4/demux0' tuning to 64200 Hz video pid 0x0437, audio pid 0x0436 status 00 | signal | snr | ber 001f | unc | status 00 | signal | snr | ber 001f | unc | status 00 | signal | snr | ber 001f | unc | status 00 | signal | snr | ber 001f | unc | status 00 | signal | snr | ber 001f | unc | Interesting, I thought. So I dug out the little mobile antenna that comes with the stick. I didn't expect to get anything working, but with that antenna I *do* get a lock even though the signal strength and quality for that is *much* worse than through the active antenna and high-quality amplifier. MythTV can tune, claiming ~20-40% signal quality (depending on which multiplex I tune to). The picture works just fine, and tzap is displaying something in between the two outputs above: # tzap -r -a 4 'TV6' using '/dev/dvb/adapter4/frontend0' and '/dev/dvb/adapter4/demux0' tuning to 64200 Hz video pid 0x0437, audio pid 0x0436 status 07 | signal 6343 | snr | ber 001f | unc 0046 | status 1f | signal 634f | snr | ber 02b0 | unc | FE_HAS_LOCK status 1f | signal 634b | snr | ber 0220 | unc | FE_HAS_LOCK status 1f | signal 6358 | snr | ber 0290 | unc | FE_HAS_LOCK status 1f | signal 634e | snr | ber 0420 | unc | FE_HAS_LOCK Conclusion: The Nova-TD stick doesn't like when the signal is too strong. Is there anything in the driver code that makes this happen? I'm thinking perhaps noone ever thought of receiving a '' value for the signal strength and use that as a kind of error signal? Stranger things have happened... ;) AntennaSignal Data feed ----- - None 0% No data Passive38% Data Active 100% No data Active + Amp 100% No data Does anybody have any idea of how to get the TD stick operational with its antennas fed from a strong signal? I've tried everything I could think of... // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB0700 device report
Can I ask you a few questions about the TD stick, 1. How is reception compared to the nova-t 500 I think it is pretty similar, though I don't have any exact numbers to give you at this time. I'm going to do an overhaul of my cabling (with a better quality amplifier and splitter); I've got a small aerial antenna which is partially blocked by trees that feeds my four inputs and the current splitters and amplifier are pretty tacky, so any differences in reception is likely to be more dependent on the cabling than the tuners. I'll try to get back with better numbers when I have better surrounding equipment. That being said, depending on which multiplex I tune to I have very varying reception on the Nova-T 500. My reception on mux 1 (with SVT channels) is usually between 70-80% according to MythTV (with the internal LNA enabled), while mux 5 (with the local channels) is varying from 40 to 60%. 2. What firmware do you use for it I now use the 1.10 firmware. Using the 03-pre1 firmware I had similar problems to yours; dvbscan found plenty of channels but MythTV failed to get a lock. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DiB0700 device report
1) system (uname -a) Linux ragnyr.garth.anden.nu 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:47:21 EDT 2007 i686 i686 i386 GNU/Linux 2) lspci-output 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 02) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 04) 01:01.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 01:01.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 01:01.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) 03:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2) 2.5) lsusb | grep Hauppauge output Bus 008 Device 002: ID 2040:9950 Hauppauge Bus 007 Device 006: ID 2040:7050 Hauppauge Bus 007 Device 005: ID 2040:9580 Hauppauge 3) DiB0700 device name (USB Stick, Nova-T 500) Nova-T 500 (PCI) Nova-T Stick (USB) Nova-T Diversity Stick (USB) 4) Application using the device (MythTV, VDR etc) MythTV 5) Symptoms (unusable, disconnect after x days, no problem) I have only had the Nova-T Stick connected to the box for the past month and that has been stable. Using multiple tuners have caused problems (MPEG decoding failures, channel lock failures, USB disconnects) in the past. I just put the Nova-T 500 card back in the box today and upgraded the firmware + drivers. For the past month, I have only had the Nova-T Stick connected and have had no problems (this device has always been the most stable). This machine is on 24/7,and MythTV has EIT scanning enabled (so there's a whole lot of channel switching going on). With the latest drivers and firmware (downloaded and compiled today), all adapters appear to be working. The Nova-TD Stick failed to tune with the previous firmware (03-pre1), but now it appears to work. MythTV has (so far) only been configured for one adapter. I'm going to configure all tuners in MythTV and see what happens. Stand by for more updates. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DiB0700 device support
I'll try to test it also. Is there any possibility that this patch gets included into main HG repository? I guess we will have to wait until Patrick comes back from his vacation. I would *not* recommend committing the patch to the HG repo. I consider it an ugly fix that doesn't take care of the root of the problem. The patch simply avoids sending kernel printk()s for repeated unknown key codes. The actual root of the problem is that these unknown key codes *are* repeated. I suspect a bug in the firmware is causing all these repeated key codes, but that's just a wild guess. Bottom line: The patch doesn't do any harm, but it does nothing to solve the actual problem. Apply it to avoid high load on syslog and ugly log messages until the actual problem is fixed, but don't commit it to the HG repo. // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DiB0700 device support
I have posted twice, with no appearance in the list, a message about remote control errors (tons of them in syslog!). I saw that you made a commit in your tree about remote control stuff. Is that related? I'll try a new build tonight. If the sample below is what your remote control errors in syslog is, the attached patch gets rid of it. --- Aug 1 13:44:26 ragnyr kernel: dib0700: Unknown remote controller key : 1E 2A Aug 1 13:44:57 ragnyr last message repeated 206 times Aug 1 13:45:58 ragnyr last message repeated 406 times Aug 1 13:46:59 ragnyr last message repeated 407 times Aug 1 13:48:00 ragnyr last message repeated 406 times Aug 1 13:49:01 ragnyr last message repeated 406 times Aug 1 13:50:02 ragnyr last message repeated 407 times --- When an unknown key code is received, it is not eaten and the module keeps yelling about it using printk()s. A bunch of times per second. Until the next valid key code is received. And this happens as soon as I use any unsupported device (like power on/off my surround system). The Nova-T IR receiver gets the IR code by accident and as a result the module starts screaming. I'm not sure but this screaming possibly killed (rebooted) my box as well. I applied the new code, tested it for a few hours, and then went to bed last night. When I woke up the box had rebooted (no mentions of why in syslog, though). After applying the attached patch, my system has been stable (about a 10 hours by now). I'm still not entirely satisfied with the RC solution for dvb-usb-remote (translating with a hardcoded list in the module and then sending (sometimes in-)appropriate key codes in to the kernel as though entered by the keyboard. Anyone know if it would be difficult to deliver the received key codes through a netlink device (or similar) that can be read by lircd? I'd prefer a solution that doesn't require a patch +recompile for each new IR thingy I use My system has one Nova-T Stick (2040:7050), one Nova-T-500 (2040:9950), and one Nova-TD Stick (2040:9580). // J diff -r a61e2628ac83 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c --- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed Aug 01 10:13:36 2007 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Wed Aug 01 15:28:33 2007 +0200 @@ -288,6 +288,7 @@ static int dib0700_rc_query(struct dvb_u } } err(Unknown remote controller key : %2X %2X,(int)key[3-2],(int)key[3-3]); + st-rc_toggle=key[3-1]; } return 0; } ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] about nova TD stick
Hi all, I just got myself a Nova-TD stick and plugged it in to one of my MythTV boxes just for the fun of it ;). I've noted on the linuxtv.org web that there is currently no support for this DVB stick. Is there any way I can help out with that? I'd consider myself a decent programmer (although I mostly work in Java nowadays) but I have done no kernel development whatsoever. How difficult do you think it would be to implement a driver for this stick? Would anyone be able to give me a push in the right direction? // J ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
