RE: [linux-dvb] Lost frontend
Surely somebody must be able to point me in the right direction getting this to work. It can't be that difficult, it all worked fine and now it is not assigning a frontend to the card. Someone must have seen this before. Please, I've been without a working DVB box for nearly three weeks now... Cheers. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bryant, Dominic (UK) Sent: 07 February 2007 13:20 To: linux-dvb@linuxtv.org Subject: [linux-dvb] Lost frontend *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Hello, this is my first post to this (or any) mailing list, so sorry if this is the wrong place for this or anything like that... About a week ago I got a Kworld DVB-T 300U box. I plugged it into my Ubuntu 6.10 system and dmesg said that it couldn't find the firmware. I downloaded the firmware, put it in the correct place (/lib/firmware I think), plugged in the DVB box, ran Kaffeine, scanned for the channels and everything worked fine. It carried on working for the next couple of days during which time I tried to install MythTV (which couldn't find any channels). The day after that I go to watch the TV using Kaffeine and it doesn't work any more. Dmesg now gives the following: [17289667.668000] usb 5-6: new high speed USB device using ehci_hcd and address 11 [17289667.80] usb 5-6: configuration #1 chosen from 1 choice [17289667.80] dvb-usb: found a 'KWorld Xpert DVB-T USB2.0' in cold state, will try to load a firmware [17289667.844000] dvb-usb: downloading firmware from file 'dvb-usb-adstech-usb2-02.fw' [17289667.932000] usb 5-6: USB disconnect, address 11 [17289667.932000] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. [17289669.684000] usb 5-6: new high speed USB device using ehci_hcd and address 12 [17289669.816000] usb 5-6: configuration #1 chosen from 1 choice [17289669.816000] dvb-usb: found a 'KWorld/ADSTech Instant DVB-T USB2.0' in warm state. [17289669.816000] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [17289669.816000] DVB: registering new adapter (KWorld/ADSTech Instant DVB-T USB2.0). [17289669.816000] dvb-usb: no frontend was attached by 'KWorld/ADSTech Instant DVB-T USB2.0' [17289669.816000] input: IR-receiver inside an USB DVB receiver as /class/input/input6 [17289669.816000] dvb-usb: schedule remote query interval to 150 msecs. [17289669.816000] dvb-usb: KWorld/ADSTech Instant DVB-T USB2.0 successfully initialized and connected. For some reason it is no longer attaching a frontand to the device. I've searched everywhere, read the past 5 or 6 months of mailing list archives and asked on the Ubuntu forum but not got anywhere. Last night I even did a manual install of the v4l drivers even though I shouldn't need to with my kernel (I thought it might help) but no change. Why would it suddenly stop working? Please help as it was great when it did work. This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ 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] Problem getting Compro DVB-T300 to work
Hartmut Hackmann wrote: Please continue testing with the driver from my personal repository for the time being. Are you sure you unloaded all modules before you tried the new drivers? There is one known issue with this card: The the tuner module *must not* be loaded before the saa7134 module, otherwise no tuner will be found, only the IF chip. This is what i see from your log. So please try the following: - install the drivers (make install as root) - remove all video related modules or better: reboot - do a modprobe saa7134, nothing else. Does it work now? Best regards Hartmut Hello Hartmut and thanks for your help :-) The driver was being loaded automatically at boot , so i made a file in /etc/hotplug/blacklist.d with saa7134 tuner and saa7134-dvb in it. Then i rebooted and checked with lsmod - no saa or v4l modules loaded - good. I saved the output of lsmod so i could see which modules would be loaded, Then i did a modprobe saa7134 as you suggested but i got the same result: Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.14 loaded ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 ACPI: PCI Interrupt :02:06.0[A] - Link [APC3] - GSI 18 (level, low) - IRQ 18 saa7134[0]: found at :02:06.0, rev: 1, irq: 18, latency: 32, mmio: 0xfddff000 saa7134[0]: subsystem: 185b:c900, board: Compro Videomate DVB-T300 [card=70,autodetected] saa7134[0]: board init: gpio is 843f00 input: saa7134 IR (Compro Videomate DV as /class/input/input5 saa7134[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7134[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 20: 01 40 01 03 03 ff 03 01 08 ff 00 87 ff ff ff ff saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 40: ff 02 00 c2 86 10 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb saa7134[0]: i2c eeprom 60: 34 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 2-0043: chip found @ 0x86 (saa7134[0]) tda9887 2-0043: tda988[5/6/7] found @ 0x43 (tuner) tuner 2-0068: chip found @ 0xd0 (saa7134[0]) saa7134[0]: registered device video0 [v4l2] saa7134[0]: registered device vbi0 saa7134[0]: frontend initialization failed These are the modules loaded by typing that one command: Module Size Used by saa7134_dvb17228 0 dvb_pll16132 1 saa7134_dvb video_buf_dvb 7236 1 saa7134_dvb dvb_core 84912 1 video_buf_dvb tda1004x 15748 1 saa7134_dvb firmware_class 11520 2 saa7134_dvb,tda1004x tuner 62312 0 saa7134 136276 1 saa7134_dvb video_buf 27140 3 saa7134_dvb,video_buf_dvb,saa7134 compat_ioctl32 8896 1 saa7134 ir_kbd_i2c 10128 1 saa7134 ir_common 37316 2 saa7134,ir_kbd_i2c videodev 27776 1 saa7134 v4l2_common18304 4 tuner,saa7134,compat_ioctl32,videodev v4l1_compat12164 2 saa7134,videodev I hope this helps. -Micah ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with KNC1 DVB-C card
The patch for TDA10023 is working fine, thank you. Best regards Vasi - Original Message From: e9hack [EMAIL PROTECTED] To: linux-dvb@linuxtv.org Sent: Thursday, February 15, 2007 5:49:50 PM Subject: Re: [linux-dvb] Problem with KNC1 DVB-C card Vasile Farcas wrote: Hello I have a problem with a KNC1 DVB-C card, first was not recognized by the system, and on a lspci -vv reported : 00:0b.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: KNC One: Unknown device 0022 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 11 Region 0: Memory at fae0 (32-bit, non-prefetchable) [size=512] Then I defined susbsystem 22 in budget-av.c, and the board appeared in /dev/dvb. Unfortunately, the result on scandvb is still the same: This is a new card with the TDA10023. You should try the patch from this mail: http://linuxtv.org/pipermail/linux-dvb/2007-February/015886.html - Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] About locking in the frontend thread
I have a issue here that has made me take a closer look at the locking done in the frontend thread, and I've found some suspicious code and an issue needing discussion. First the two suspicious code snippets: 1: In dvb_frontend_add_event e-status is set after the lock is released. This I think can cause dvb_frontend_get_event to return a incomplete/old event. The structure of the ring buffer should remain intact so there is no potential for catastrophic failure. 2: In dvb_frontend_get_event, the code checks if the queue is empty without taking the lock (this itself is ok), and waits if it is. However it does not check again wether there is actually any pending events after taking the lock. This causes a condition so that if several threads are waiting in get_event at the same time many of them can get spurious extra events out (seemingly an entire extra round arount the ring buffer). Still no catastrophic failure that I can think of though. Finally to my actual issue: The events are added to the event queue at the very beginning of swzigzag, and the frontend thread holds fepriv-sem. poll() will immediatly report that new events are available, however calling GET_EVENT on the frontend handle will block untill swzigzag has completed and gives up the lock. Even on non-blocking filehandles. This can for some frontends take very long time and the calling program will just hang, even when using nonblocking io and poll() correctly. Would it be possible to either release the lock and give the ioctl a shot at returning or delay the actual adding of the event till the end of swzigzag? Regards Sigmund Augdal ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] 2.6.20 no devices in /dev
On 2/18/07, Matthew Schultz [EMAIL PROTECTED] wrote: Did you try modprobe cx88-dvb? Also check to make sure your kernel is compiled with Automatic kernel module loading so that you don't have to load the driver manually Stupid me! I was building all modules except DVB/ATSC Support for cx2388x based TV cards and to debug the issue I was thinking of strangest issues instead of the simplest human error that could happen. Sorry for the noise on the list! Matt On 2/18/07, Pino Gargiulo [EMAIL PROTECTED] wrote: Hello! This weekend I upgraded to 2.6.20. My tuning board is found CORE cx88[0]: subsystem: 0070:9002, board: Hauppauge Nova-T DVB-T [card=18,autodetected] but nothing appears in /dev/dvb. From what I understand the device inodes are created by udevd that gets info from /sys/class/dvb but this is also empty. Tried also 2.6.20-git14but no result. Any hints? What an I doing wrong? With 2.6.19.1 all works fine TIA /PG ___ 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 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Driver loading race condition
I have a Twinhan VP-1025 DVB-S card (bt878) and a Terratec DTT (dtt200u) USB2 device. It is a lottery as to which gets adapter 0 and adapter 1 at boot time. Is there a way to delay one driver's startup or module load so that the assignment of adapter numbers is the same each time the host is booted, or is there some other way to make this happen? (probably a common question but can't find anything in the archives/ FAQ/wiki, sorry) Thanks. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] cinergy 1200 DVB-C install help neeeded
hi there arround (already wrote some days ago, but think, that my mail got lost in space) okthe things I have done: I bought a DVB-C card (as mentioned in the topic) because it was in the compatibility-listwell, ok, now we know, that there is another tuner chip (tda100023) and that ne has to use a patch to get that running. what I have done is: tv-backend:/usr/local/dvb_new#hg clone http://linuxtv.org/hg/v4l-dvb everything I tried with doing a bzcat tda10023.diff.bz2 |patch -p1 failed could please any of you proide a dummy's cook-book for me how to get that running ? thanks in advance! kind regards peter -- Peter Loeffler ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb_usb_dib0700 based devices and randomusb disconnects
Matt Doran write: ... the developers thought this might have been caused by a bug that only got fixed post-2.6.20. I haven't had a chance to try this yet, but you can read about it here: http://www.linuxtv.org/pipermail/linux-dvb/2007-February/015808.html Using the Nova-T-500, I tried - 2.6.20 with the usb patch referred to by your post above - 2.6.20-git14 without the usb patch Both didn't help. Within a day, mostly after a couple of hours, I got the disconnect oops... Cheers, Arnold ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] cu1216.ko: won't install on Mantis branch. Please fix it.
Symptom: If you do make install, cu1216.ko won't get copied. This problem can be fixed by adding a newline in the end of file linux/drivers/media/dvb/frontends/Makefile. Here is the last line of that file: obj-$(CONFIG_DVB_CU1216) += cu1216.o And because that line does not end with a newline, install scripts fail with it. The problematic file is: linux/drivers/media/dvb/frontends/Makefile Regards, Marko Ristola ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Lost frontend
'morning Bryant, I might be able to help (as unlikely as that seems to me :-) I have a mythtv box which runes SuSE 10.0 on AMD64, and which uses two Avermedia 771 cards. Its worked almost perfectly now for a year-ish; the only problem that happens is that very rarely (about once every 4 months) the frontends vanish, and can be a real pain to recover. Anyhow, here is what I do when this happens: When everything works, I note how the cards should be configured: Number Card Name --- 0-TV Bt878 Driver bttv 1-TV Bt878 0-DVBAvermedia DVB-T 771 Driver bt878, driver mt352 1-DVBAvermedia DVB-T 771 Notes: - The mt352 is the Zarlink MT352 DVB-T Demodulator Driver - The DVB entries are the front-ends I think. Anyhow, they require two drivers/kernel modules, as shown above. - Modprobe the drivers/kernel modules. - I need to shutdown and then restart the computer between changes. Restart is not enough. - I seem to need to run the MAKEDEV-DVB.sh script as root to create the /dev devices. - Shutdown and then start up lots. I hope this helps; let me know if I can provide any other info. Thanks, Tim. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Mantis driver: making cu1216.ko work for me
Manu, Is there a way that how my patches could be applied into the Mantis development tree? Is there some way that they could be delivered into the main Linux development tree some day? Of course, I need to supply small patches. I've noticed on this list that you use cu1216 also. It would be good, if both my card and yours would work with the same drivers. Maybe there are other cu1216 cards or use cases out there? Maybe it would be good to identify the differing devices somehow to be able to distinguish them? Some needed changes: mantis_dma.c: DMA START/STOP: MANTIS_GPIF_ADDR: don't turn 0x3000 (or something) flag off or FE_LOCK status reading fails. mantis_dma.c: dvb_dmx_swfilter_204 / dvb_dmx_swfilter selection issue: I need dvb_dmx_swfilter_204() urgently. How the selection could be handled in the driver without every user patching the kernel? A module parameter? some other way? cu1216.c: I needed some working heuristics to be able to get FE_LOCK. The current Mantis implementation doesn't work for me. My solution was to simplify cu1216.c so that it works with dvb_core.c's own lock acquiring heuristics. - dvb_core.c has the responsibility to figure out correct inversion. - dvb_core.c has the responsibility to figure out when it has a lock. - cu1216.c, parameter setting function must figure out the best gain. - cu1216.c informs dvb_core.c to wait minimum of 50ms for FE_LOCK to come up (settings-min_delay_ms). Regards, Marko Ristola ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] kernel panic when tuning after reboot
Hello!
I'm working on a sort of appliance that must suspend/resume in minimal time.
The current config is 2.6.20 kernel and Nova-T DVB card. I can suspend and
resume the kernel as I said in an older posting but cannot tune anymore. If
I try to do it from kaffeine when I select for the second time aTV station I
get a kernel panic in mm/slab.c:610 with invalid opcode:[#2]
Maybe this is due to this kernel bug that occurs when suspending.
0[ cut here ]
kernel BUG at drivers/media/video/video-buf-dvb.c:58!
invalid opcode: [#1]
Modules linked in: cx22702 cx88_dvb cx88_vp3054_i2c dvb_pll video_buf_dvb
cx8800
cx8802 cx88xx ir_common nvidia(P) i2c_algo_bit tveeprom compat_ioctl32
videodev
v4l2_common btcx_risc video_buf v4l1_compat i2c_nforce2
CPU:0
EIP:0060:[dc97805c]Tainted: P VLI
EFLAGS: 00010286 (2.6.20 #23)
EIP is at videobuf_dvb_thread+0x5c/0x117 [video_buf_dvb]
eax: fffc ebx: 0246 ecx: cfd4cbec edx: d6cf9f7c
esi: cfd4cb80 edi: d9e8106c ebp: fffc esp: d6cf9fb0
ds: 007b es: 007b ss: 0068
Process cx88[0] dvb (pid: 2456, ti=d6cf8000 task=c149a550 task.ti=d6cf8000)
Stack: d2f73df0 d2f73df0 d2f73df0 d9e8106c dc978000 c01280a4 0001
c0128032 c0104603 d2f73de8
Call Trace:
[dc978000] videobuf_dvb_thread+0x0/0x117 [video_buf_dvb]
[c01280a4] kthread+0x72/0x97
[c0128032] kthread+0x0/0x97
[c0104603] kernel_thread_helper+0x7/0x10
Ideas or suggestion on the possible cause?
Thanks to all
/PG
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb_usb_dib0700 based devices and randomusb disconnects
Arnold Schulz wrote: Matt Doran write: ... the developers thought this might have been caused by a bug that only got fixed post-2.6.20. I haven't had a chance to try this yet, but you can read about it here: http://www.linuxtv.org/pipermail/linux-dvb/2007-February/015808.html Using the Nova-T-500, I tried - 2.6.20 with the usb patch referred to by your post above - 2.6.20-git14 without the usb patch Both didn't help. Within a day, mostly after a couple of hours, I got the disconnect oops... Hmmm, I have the Nova-T 500 PCI dual tuner, and 2.6.20 was a massive improvement. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem getting Compro DVB-T300 to work
Hi micah schrieb: Hartmut Hackmann wrote: Please continue testing with the driver from my personal repository for the time being. Are you sure you unloaded all modules before you tried the new drivers? There is one known issue with this card: The the tuner module *must not* be loaded before the saa7134 module, otherwise no tuner will be found, only the IF chip. This is what i see from your log. So please try the following: - install the drivers (make install as root) - remove all video related modules or better: reboot - do a modprobe saa7134, nothing else. Does it work now? Best regards Hartmut Hello Hartmut and thanks for your help :-) The driver was being loaded automatically at boot , so i made a file in /etc/hotplug/blacklist.d with saa7134 tuner and saa7134-dvb in it. Then i rebooted and checked with lsmod - no saa or v4l modules loaded - good. I saved the output of lsmod so i could see which modules would be loaded, Then i did a modprobe saa7134 as you suggested but i got the same result: Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.14 loaded ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18 ACPI: PCI Interrupt :02:06.0[A] - Link [APC3] - GSI 18 (level, low) - IRQ 18 saa7134[0]: found at :02:06.0, rev: 1, irq: 18, latency: 32, mmio: 0xfddff000 saa7134[0]: subsystem: 185b:c900, board: Compro Videomate DVB-T300 [card=70,autodetected] saa7134[0]: board init: gpio is 843f00 input: saa7134 IR (Compro Videomate DV as /class/input/input5 saa7134[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7134[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 20: 01 40 01 03 03 ff 03 01 08 ff 00 87 ff ff ff ff saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 40: ff 02 00 c2 86 10 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb saa7134[0]: i2c eeprom 60: 34 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 2-0043: chip found @ 0x86 (saa7134[0]) tda9887 2-0043: tda988[5/6/7] found @ 0x43 (tuner) tuner 2-0068: chip found @ 0xd0 (saa7134[0]) saa7134[0]: registered device video0 [v4l2] saa7134[0]: registered device vbi0 saa7134[0]: frontend initialization failed These are the modules loaded by typing that one command: Module Size Used by saa7134_dvb17228 0 dvb_pll16132 1 saa7134_dvb video_buf_dvb 7236 1 saa7134_dvb dvb_core 84912 1 video_buf_dvb tda1004x 15748 1 saa7134_dvb firmware_class 11520 2 saa7134_dvb,tda1004x bus tuner 62312 0 saa7134 136276 1 saa7134_dvb video_buf 27140 3 saa7134_dvb,video_buf_dvb,saa7134 compat_ioctl32 8896 1 saa7134 ir_kbd_i2c 10128 1 saa7134 ir_common 37316 2 saa7134,ir_kbd_i2c videodev 27776 1 saa7134 v4l2_common18304 4 tuner,saa7134,compat_ioctl32,videodev v4l1_compat12164 2 saa7134,videodev I hope this helps. -Micah Hm, i have a very similar card, it works for me. But i don't have a 64 bit system. I can imagine 2 possible reasons - part of the driver is not 64 bit clean. - (more likely) The driver currently does not prevent a collision on the i2c bus if the tuner is attached after i2c gate of the tda10046. This collision can only occur during card initialization. I have an idea how to overcome this, but it is not yet implemented. Meanwhile you can do the following: please add the following to your modprobe,conf.local: options saa7134 i2c_scan=1 options tuner debug=1 options tda1004x debug=1 This gives us additional information what exactly happens. Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Implement repeat key handling in budget-ci IR
The attached patch contains the last set of changes to the budget-ci IR
handling which makes it use the repeat handling of the input subsystem.
This allows some code simplification, makes sure that repeat key presses
are reported as such and also allows the debounce hack to be removed
altogether.
In addition a couple of static variables were removed which would have
confused the IR code if more than one card is used.
Signed-off-by: David Härdeman [EMAIL PROTECTED]
--
David Härdeman
diff -r 5884d8239fe1 linux/drivers/media/dvb/ttpci/budget-ci.c
--- a/linux/drivers/media/dvb/ttpci/budget-ci.c Sun Feb 18 23:10:14 2007 -0200
+++ b/linux/drivers/media/dvb/ttpci/budget-ci.c Tue Feb 20 01:39:48 2007 +0100
@@ -73,20 +73,14 @@
#define SLOTSTATUS_READY 8
#define SLOTSTATUS_OCCUPIED (SLOTSTATUS_PRESENT|SLOTSTATUS_RESET|SLOTSTATUS_READY)
-/* Milliseconds during which key presses are regarded as key repeat and during
- * which the debounce logic is active
+/*
+ * Milliseconds during which a key is regarded as pressed.
+ * If an identical command arrives within this time, the timer will start over.
*/
-#define IR_REPEAT_TIMEOUT 350
+#define IR_KEYPRESS_TIMEOUT 250
/* RC5 device wildcard */
#define IR_DEVICE_ANY 255
-
-/* Some remotes sends multiple sequences per keypress (e.g. Zenith sends two),
- * this setting allows the superflous sequences to be ignored
- */
-static int debounce = 0;
-module_param(debounce, int, 0644);
-MODULE_PARM_DESC(debounce, ignore repeated IR sequences (default: 0 = ignore no sequences));
static int rc5_device = -1;
module_param(rc5_device, int, 0644);
@@ -99,11 +93,24 @@ struct budget_ci_ir {
struct budget_ci_ir {
struct input_dev *dev;
struct tasklet_struct msp430_irq_tasklet;
+ struct timer_list timer_keyup;
char name[72]; /* 40 + 32 for (struct saa7146_dev).name */
char phys[32];
struct ir_input_state state;
int rc5_device;
+ u32 last_raw;
+ u32 ir_key;
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,19)
+ bool have_command;
};
+#else
+ int have_command;
+};
+enum {
+ false = 0,
+ true = 1
+};
+#endif
struct budget_ci {
struct budget budget;
@@ -125,13 +132,8 @@ static void msp430_ir_interrupt(unsigned
{
struct budget_ci *budget_ci = (struct budget_ci *) data;
struct input_dev *dev = budget_ci-ir.dev;
- static int bounces = 0;
- int device;
- int toggle;
- static int prev_toggle = -1;
- static u32 ir_key;
- static int state = 0;
u32 command = ttpci_budget_debiread(budget_ci-budget, DEBINOSWAP, DEBIADDR_IR, 2, 1, 0) 8;
+ u32 raw;
/*
* The msp430 chip can generate two different bytes, command and device
@@ -143,7 +145,7 @@ static void msp430_ir_interrupt(unsigned
* bytes and one or more device bytes. For the repeated bytes, the
* highest bit (X) is set. The first command byte is always generated
* before the first device byte. Other than that, no specific order
- * seems to apply.
+ * seems to apply. To make life interesting, bytes can also be lost.
*
* Only when we have a command and device byte, a keypress is
* generated.
@@ -152,53 +154,35 @@ static void msp430_ir_interrupt(unsigned
if (ir_debug)
printk(budget_ci: received byte 0x%02x\n, command);
- /* Is this a repeated byte? */
- if (command 0x80)
- return;
+ /* Remove repeat bit, we use every command */
+ command = command 0x7f;
/* Is this a RC5 command byte? */
if (command 0x40) {
- state = 1;
- ir_key = command 0x3f;
+ budget_ci-ir.have_command = true;
+ budget_ci-ir.ir_key = command 0x3f;
return;
}
/* It's a RC5 device byte */
- if (!state)
+ if (!budget_ci-ir.have_command)
return;
- state = 0;
- device = command 0x1f;
- toggle = command 0x20;
-
- if (budget_ci-ir.rc5_device != IR_DEVICE_ANY budget_ci-ir.rc5_device != device)
+ budget_ci-ir.have_command = false;
+
+ if (budget_ci-ir.rc5_device != IR_DEVICE_ANY
+ budget_ci-ir.rc5_device != (command 0x1f))
return;
- /* Ignore repeated key sequences if requested */
- if (toggle == prev_toggle ir_key == dev-repeat_key
- bounces 0 timer_pending(dev-timer)) {
- if (ir_debug)
- printk(budget_ci: debounce logic ignored IR command\n);
- bounces--;
- return;
- }
- prev_toggle = toggle;
-
- /* Are we still waiting for a keyup event? */
- if (del_timer(dev-timer))
+ /* Is this a repeated key sequence? (same device, command, toggle) */
+ raw = budget_ci-ir.ir_key | (command 8);
+ if (budget_ci-ir.last_raw != raw || !timer_pending(budget_ci-ir.timer_keyup)) {
ir_input_nokey(dev, budget_ci-ir.state);
-
- /* Generate keypress */
- if (ir_debug)
- printk(budget_ci: generating keypress 0x%02x\n, ir_key);
- ir_input_keydown(dev, budget_ci-ir.state, ir_key, (ir_key (command 8)));
-
- /* Do we want to delay the keyup event? */
- if (debounce) {
- bounces = debounce;
- mod_timer(dev-timer, jiffies + msecs_to_jiffies(IR_REPEAT_TIMEOUT));
- } else {
- ir_input_nokey(dev, budget_ci-ir.state);
- }
+ ir_input_keydown(dev, budget_ci-ir.state,
+
[linux-dvb] can anyone reply
Can someone, anyone, reply to this dummy message to reassure me that my emails actually appear on this list. None have been answered in the past. Thanks, Phil T. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] can anyone reply
they do. just nobody wants to help you. typical open source attitude. -t On 2/20/07, barny rabbit [EMAIL PROTECTED] wrote: Can someone, anyone, reply to this dummy message to reassure me that my emails actually appear on this list. None have been answered in the past. Thanks, Phil T. ___ 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] can anyone reply
timecop wrote: they do. just nobody wants to help you. typical open source attitude. -t On 2/20/07, barny rabbit [EMAIL PROTECTED] wrote: Can someone, anyone, reply to this dummy message to reassure me that my emails actually appear on this list. None have been answered in the past. Thanks, Phil T. Phil, just be patient and keep trying. I know its frustrating, but what can you do? --- The sad reality is that there are precious few developers around here and most, if not all, provide assistance on their free time ... which then cuts into development time...which is also done on free time. Maybe no one, including run-of-the-mill general users, knows or has an answer to your questions. Perhaps those who do know the answer, are busy with other projects and real life, or aren't reading the list currently. The activity/participation, levels on the v4l and dvb lists have dropped a fair amount, from my perspective, in the recent months ... so please don't think that you're the only one whose messages have gone unanswered ( there have been many!). As an alternative, you can also try posting your questions on various user forums to try to maximize your return. I have no idea what the source of timecop's resentment is, but it certainly sounds misplaced. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] can anyone reply
Hi Phil, barny rabbit schrieb: Can someone, anyone, reply to this dummy message to reassure me that my emails actually appear on this list. None have been answered in the past. Sorry, but a good start is to know the netiquette. I usually do ignore posts from fake-email-adresses, comined with fake Names ;) Frank ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb_usb_dib0700 based devices and random usb disconnects
Matt Doran wrote: Arnold Schulz wrote: Looks like the problem of Nova-T-500, which also uses dib0700 !?! There have been several posts in this list, eg: http://www.linuxtv.org/pipermail/linux-dvb/2007-February/015716.html Yes, that's looks like the same problem. We haven't got a solution, however we've found that using the 2.6.20 kernel greatly improves stability. Using the 2.6.19 kernel I got Oops' every day or two, but since upgrading to 2.6.20, it's only disconnected once in about 3 weeks. So it's not perfect, but it's much, much better. I asked a few questions in the linux-usb-dev mailing list. And one of the developers thought this might have been caused by a bug that only got fixed post-2.6.20. I haven't had a chance to try this yet, but you can read about it here: http://www.linuxtv.org/pipermail/linux-dvb/2007-February/015808.html I applied that patch on 2.6.20 and haven't got any kernel oops since then (Feb 7) and still keep my fingers crossed... =) /Richard ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
