Re: [linux-dvb] libdvben50221 docs and debuging
On Fri, November 16, 2007 06:52, Ben Bucksch wrote: > I am trying to use libdvben50221 from linuxtv-dvb-apps (version 20070114 > from Gentoo) to drive the CI/CA/CAM for some encrypted channels. I get > some printouts on the console, but it doesn't work, the channel is not > decrypted. I don't know if you've done this, but it would perhaps be a good idea to try the "gnutv" application first (it uses libdvben50221 and is in the same repo) to make sure that everything works as expected. If gnutv works, then it might be time to start comparing your programs use of libdvben50221 to that of gnutv... -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Non blocking IO on dvr0 device
On Fri, November 9, 2007 03:33, Felix Domke wrote: > Banana Banana wrote: >> On Nov 9, 2007 12:22 AM, Simon Hargreaves <[EMAIL PROTECTED]> wrote: >>> I'm using >>> 2.6.12-gentoo-r6 #1 SMP kernel. >> Try a more recent kernel? > No, this is not the correct response to a bug. Of course it is when the poster's kernel is more than 2 years old (2.6.12 was released on June 17, 2005). > Or do you remember a bug which was present in that kernel version, and > fixed later? In that case, why don't you point to the diff? It would take a superhuman developer to be able to recall every single patch that went in between 2.6.12 and now and to correctly analyze the effects of, and interactions between, every single patch. > This was a (perfectly fine) user question, not a developer request. His > question was if there is or was a known bug regarding non-blocking IO on > dvr0. If he wanted to be a kernel developer, he would probably have > posted a patch fixing (or at least explaining) the issue. But he asked > if there is a known issue. Not what he could do to maybe workaround that > problem. And it was a perfectly straightforward answer, the DVB devs would be helped if the bug could be reproduced with more recent kernel versions as it gives a much more solid base from which to start debugging (and if it's not present in recent kernels, hey, problem solved). The request for a test with a recent kernel could of course have been expressed in a less terse manner, but that's something else. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] libdvbapi clarification
On Wed, July 11, 2007 09:31, David Härdeman wrote: > Ok, now I'm confused...when I use one filter by calling > dvbdemux_set_section_filter with filter[0] and mask[0] set to something, I > get sections. > > If I use two filters by calling dvbdemux_set_section_filter with > filter[0], mask[0], filter[3], mask[3] set to something, I get no sections > at all... Ok, I understand what I did wrong now...I assumed that each byte of filter[x] was an independent table id filter, but each is for a different byte of the section (so the filter can match on more than just the table_id). -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] libdvbapi clarification
On Tue, July 10, 2007 10:56, Marcel Siegert wrote: > On Tuesday 10 July 2007, David Härdeman wrote: >> I'm trying to understand the dvbdemux_set_section_filter function in >> dvp-apps/lib/libdvbapi/dvbdemux.c (lines 74 - 93). ... > > if you filter a section you can filter on e.g. the table id but NOT on the > size ect. (those are used as byte 2 + 3 of a section) Ok, now I'm confused...when I use one filter by calling dvbdemux_set_section_filter with filter[0] and mask[0] set to something, I get sections. If I use two filters by calling dvbdemux_set_section_filter with filter[0], mask[0], filter[3], mask[3] set to something, I get no sections at all... Do I need to do anything special to use multiple filters? Second, unused filter and mask values are set to 0x00, but how does the API distinguish between an unused filter/mask pair and a request for all sections? It seems that if I call dvbdemux_set_section_filter with mask[0] = 0x00 and filter[0] = 0x00 I do get all sections... -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] libdvbapi clarification
On Tue, July 10, 2007 10:56, Marcel Siegert wrote: > On Tuesday 10 July 2007, David Härdeman wrote: >> I'm trying to understand the dvbdemux_set_section_filter function in >> dvp-apps/lib/libdvbapi/dvbdemux.c (lines 74 - 93). >> >> It used to take 16 filter and 16 mask parameters, but then it was >> changed 15 months ago to take 18 filter and 18 mask parameters, >> then it throws away 2 of each: ... > if you filter a section you can filter on e.g. the table id but NOT on the > size ect. > (those are used as byte 2 + 3 of a section) > > so if you would read the source normally, you would think you can filter > on those values. > having the two "unused" values within the filter array it makes life > easier to count the bytes > you want to filter and to set the right mask. > it can be more irretating than usefull, i must admit. Thanks for the prompt reply :) The "hole" at bytes 2 and 3 seems like a typical implementation detail that a library should hide from its users. Wouldn't it be saner to change the API so that the function takes 16 filter/mask values and adds the unused bytes itself? -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] libdvbapi clarification
I'm trying to understand the dvbdemux_set_section_filter function in
dvp-apps/lib/libdvbapi/dvbdemux.c (lines 74 - 93).
It used to take 16 filter and 16 mask parameters, but then it was changed
15 months ago to take 18 filter and 18 mask parameters, then it throws
away 2 of each:
int dvbdemux_set_section_filter(int fd, int pid,
uint8_t filter[18], uint8_t mask[18],
int start, int checkcrc)
{
struct dmx_sct_filter_params sctfilter;
memset(&sctfilter, 0, sizeof(sctfilter));
sctfilter.pid = pid;
memcpy(sctfilter.filter.filter, filter, 1);
memcpy(sctfilter.filter.filter+1, filter+3, 15);
memcpy(sctfilter.filter.mask, mask, 1);
memcpy(sctfilter.filter.mask+1, mask+3, 15);
What is the purpose of this?
Second, how is the mask used? Would for example a filter value of 0x50 and
a mask of 0xf0 mean that all sections 0x50 - 0x5f would pass through the
section filter?
--
David Härdeman
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Possible bug in cx88-dvb?
On Wed, July 4, 2007 16:06, Hanno Zulla wrote: > On my system, there is a visible skip of video output when this shows up > the syslog. Very annoying. When I was playing around with the IR handling code of the budget-ci driver, I added some debug printk's to the driver and as soon as they fired I saw skipping video. It turned out that the printk's themselves added enough latency in a fast path to upset the kernel/driver/card. So if the messages are harmless, perhaps you could (as a test to rule this theory out) try to compile the driver with the "cx88_wakeup: blabla" printk removed? -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-C Questions for Holland
On Fri, Jun 15, 2007 at 07:17:59PM +0200, Peter Maersk-Moller wrote: >Hi. > >Has any one been using Budget and Technotrend cards for receiving >digital Cable TV from Casema in Holland ? Yes, I use a Technotrend Budget C-1500 with Casema in The Hague. >If yes, which frequencies, qam and symbol rates are you using ? I use the ones from the nl-Casema scan file in the dvb-apps repo (i.e. initial frequency 37200, symbol rate 6875000, qam64). >Is the qam 64 and the symbol rate 6.875.000? Yes >And is this table valid for the Leiden/Leyden area today ? >http://www.digitalekabeltelevisie.nl/techniek/tvd.shtml No idea, my experience with Casema is that their lineup changes quite frequently (with the less common channels changing all the time). >Which CAM are you using ? AlphaCrypt (*not* the AlphaCrypt Light module), since it supports irdeto2 which is what Casema uses (AFAIK). -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-c & CI, but no picture?
On Thu, June 7, 2007 12:35, Simon Baxter wrote: >> > David Härdeman wrote: >> What is the output from gnutv when you execute it like above? >> >> (If I record a stream using gnutv to a file without having working >> encryption, I get a file which is properly recognised by xine as a MPEG >> stream but which just produces a black window). > > I get a file: > > gnutv -channels channels.conf -out stdout ONE > outfile.mpg > [EMAIL PROTECTED] ~]# file outfile.mpg > outfile.mpg: data >... > [EMAIL PROTECTED] ~]# mplayer -identify outfile.mpg | less > Can't open joystick device /dev/input/js0: No such file or directory > Can't init input joystick > mplayer: could not connect to socket > mplayer: No such file or directory > Failed to open LIRC support. > You will not be able to use your remote control. > Compiled with runtime CPU detection. >... > Playing outfile.mpg. > TS file format detected. > DEMUX OPEN, AUDIO_ID: -1, VIDEO_ID: -1, SUBTITLE_ID: -2, > PROBING UP TO 200, PROG: 0 > ID_VIDEO_ID=5011 > ID_VIDEO_ID=5011 Yes, I think that's the expected output if everything but the decryption stage is working. And unfortunately I'm all out of ideas on what is missing for your setup to work (as I've said, it works for me without any extra steps). Do you know if you need to do something in the CAM menu (e.g. enter a parental pin or something) to activate the CAM? -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-c & CI, but no picture?
On Wed, June 6, 2007 10:25, Simon Baxter wrote: > David Härdeman wrote: >> Try something like: >> >> gnutv -channels channel.conf -out stdout "NAME_OF_A_CHANNEL" > >> outfile.mpg >> >> Let that run for a while and then see if you can play "outfile.mpg" >> with xine or mplayer. > > I get a file, but not a playable one. Am trying Kaffeine - as I think > gnutv won't decrypt? (and my provider only sends encrypted channels) gnutv decrypts just fine (my provider also only sends encrypted channels). When you say it's not playable, does that mean you get a black window when you try to play it or does xine/mplayer refuse to play the file at all? What is the output from gnutv when you execute it like above? (If I record a stream using gnutv to a file without having working encryption, I get a file which is properly recognised by xine as a MPEG stream but which just produces a black window). -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-C budget decoding - no picture
On Wed, June 6, 2007 20:45, Simon Baxter wrote: > When I use the DVB channels menu in Kaffeine to scan for channels, the > SIGNAL bar is either 0% or 1% - never higher. It scans and finds channels > fine, and the card works fine under windows so I assume there is enough > signal strength. > > Can you tell me what level you get for SIGNAL? I also get bogus signal strength values (as in - impossibly low ones) on the same card, so I don't think that is your problem. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-c & CI, but no picture?
On Tue, June 5, 2007 10:27, Simon Baxter wrote: > Sorry - can you help me with the syntax for gnutv? I only get the menu!! Try something like: gnutv -channels channel.conf -out stdout "NAME_OF_A_CHANNEL" > outfile.mpg Let that run for a while and then see if you can play "outfile.mpg" with xine or mplayer. If you don't have a channel.conf you need to create one using the zap utils. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-c & CI, but no picture?
On Mon, June 4, 2007 21:31, Simon Baxter wrote: > I've recently got my TT-1500C, CI and Irdeto CAM working. My cable > provider only provides encrypted channels, so can't do any testing > free-to-air channels. ... > Can anyone suggest any other testing I can do?? It looks like it should > be working? I'd suggest you try using the basic gnutv application from the dvb-tools repo first and see if it works. It just needs a correct channel.conf file to operate and it can also let you use the CAM menu (so you can make sure the communication with the CAM is ok). -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Remote control input event problem with recent kernels
On Wed, May 30, 2007 at 10:33:41PM +0100, Tony Houghton wrote: >I've got 2 DVB-T PCI cards, a Hauppauge Nova-T wwhich uses the budget_ci >(even though it doesn't have a CI) module and a K-World cx88-based card. >I've always used the Hauppage's remote because I've had the card longer, >and the K-World's has fewer useful keys. I used to have to patch the >budget_ci driver's key map, but once that was done it worked well, >generating appropriate press, repeat and release events. > >With the driver in recent kernels (2.6.20 onwards?) I no longer have to >patch it, but the remote doesn't work so well. While holding a key down >I get a series of alternate press and release events with no repeat >events. Sometimes I have to hold down a key for a few seconds before it >starts sending events. > >I tried the K-World remote too. Each time I press a key it generates >just one press event then a release event (even if I haven't released >the key). Like with the Hauppauge remote it doesn't generate any repeat >events, but unlike the Hauppauge it doesn't send further press/release >events until I release the key and press it again, or another key. > >Have I missed some setup detail? Is there a patch or anything? There were some more bugfixes to the IR handling of the budget-ci driver committed to recent -rc linux kernels and to the hg repo, please try with that. If it doesn't work with the most recent version of the driver, please load the module with debug=1 and send the output from dmesg. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: scan files for the past 4 months
On Tue, Apr 10, 2007 at 09:35:32PM +0200, Christoph Pfister wrote: 2007/4/10, Christoph Pfister <[EMAIL PROTECTED]>: Hi, I have been working on those files (most of them were fwded by me; but I'll try to catch the others too). No critical comment was posted to these changes, so I assume that they're ok and should finally go in. Last round (please resend your file if you posted it before 01.04.2007 and it doesn't appear in this list or the list in the previous mail). Note that this here is just a listing; the individual messages weren't processed as in the first mail. I think this one wasn't included (sent 5 Feb). -- David Härdeman # Casema Netherlands # freq sr fec mod C 37200 6875000 NONE QAM64 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with keys repeated
On Tue, March 6, 2007 23:59, Ville-Pekka Vainio said: > Kirjoitit viestissäsi (lähetysaika keskiviikko, 7. maaliskuuta 2007 > 00:18:49): >> I'm not quite sure I follow, you have the same kind of problem (i.e. >> that a continous keypress generates repeat events)? But then you talk >> about time before the keypress is generated? > > I'll try to explain better how the remote works for me. I'm not sure if > the > problem is really the same, but it sounded similar, so I decided to tell > about it on this thread... > > At first, maybe for about ten keypresses after boot or reloading the > drivers, the remote works perfectly. The event happens immediately > after pressing the key. > > Then it goes into a mode where I have to press the key for a long time > before anything happens. This is very weird, the keypress event (as opposed to the repeat or release event) should be instant. Could you try running the module with ir_debug=1 and send me the output of dmesg after such a run. It would be good if you could combine it with evtest so that there are timestamps to correlate the different key events. > And when the event actually occurs, then it often also > generates a repeat. I tried repeat=0 to stop this unwanted repeat from > occurring, but it didn't work very well. > > I tried to get an evtest log of the situation: > > Event: time 1173221474.755429, type 1 (Key), code 103 (Up), value 1 > Event: time 1173221474.755434, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1173221475.155711, type 1 (Key), code 103 (Up), value 2 > Event: time 1173221475.155716, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1173221475.219704, type 1 (Key), code 103 (Up), value 0 > Event: time 1173221475.219707, type 0 (Reset), code 0 (Reset), value 0 This looks like it should as far as I can tell...400 ms from first keypress until the first repeat, and then a key release event about 75 ms later. The delay until the first repeat event can be changed using kbdrate with the "-d" parameter. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with keys repeated
On Tue, Mar 06, 2007 at 06:52:48PM +0200, Ville-Pekka Vainio wrote: David Härdeman kirjoitti viestissään (lähetysaika tiistai, 6. maaliskuuta 2007 15:26:20): On Tue, March 6, 2007 13:20, Dom H said: > I've updated my machine and now my Logitech remote is giving me multiple > events on a single keypress. I've already answered your question on the LIRC list. Did you try using kbd-utils to change the repeat rate? You might also try loading ir-common with the parameter "repeat=0". I've been having the same kind of problems with Technotrend C-1500 and it's bundled remote (a grey one). I tried loading ir-common with repeat=0, but still it seems to take quite a long time before the keypress gets generated. It feels like I anyway have to invoke some kind of "repeat handling" to get the keypress through. I'm not quite sure I follow, you have the same kind of problem (i.e. that a continous keypress generates repeat events)? But then you talk about time before the keypress is generated? For repeat or no repeat, the keypress should be generated instantly (it is not the key down event but the key up event that might be delayed with the repeat handling). Then, if I keep pressing the key after one keypress has been generated, it sometimes generates no repeat keypresses, sometimes one or two more keypresses. And all this with repeat=0. As you might imagine, controlling VDR is a bit of a challenge right now. I had no problems with this remote before the recent changes to the IR handling. Could you explain why you tried using repeat=0 in the first place? -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with keys repeated
On Tue, Mar 06, 2007 at 04:38:17PM +, Dom H wrote: Forgot to say, my card uses the cx88 driver. I'm sorry but my knowledge is mostly on the ir handling of the budget-ci driver. I'll forward this to the linux-dvb list...hopefully someone with more insight in the cx88 driver will be able to help you with the repeat rate issue... -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with keys repeated
On Tue, March 6, 2007 13:20, Dom H said: > I've updated my machine and now my Logitech remote is giving me multiple > events on a single keypress. I use the Logitech learning remote as a > relacement for the original (which works fine) Card is a Hauppauge Win-TV > Nova-T which I believe uses the budget-ci driver, I've heard this has been > changed recently and this may be the problem? I've tried booting with a > previous kernel but this doesn't work either as I assumed it was the built > in driver changing that was causing the problem. Confused. I've already answered your question on the LIRC list. Did you try using kbd-utils to change the repeat rate? You might also try loading ir-common with the parameter "repeat=0". -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] module parameters "ir_debug" budget_ci
On Tue, Feb 27, 2007 at 09:50:18PM +0100, [EMAIL PROTECTED] wrote: Hi, I am having same troubles as Jouni in this e-mail chain. http://www. mail-archive.com/linux-dvb@linuxtv.org/msg21617.html I tried to do modprobe budget_ci ir_debug=1 rc5_device=255 modprobe says -1 Unknown symbol in module and dmesg tells budget_ci: Unknown parameter 'rc5_device' ... 'ir_debug' Could you please provide the unedited messages. "Unknown symbol in module" usually means that you've specified a parameter which is not known to the module, or that the module has been built in a different environment than the kernel. Does the compiling need something special to make these module parameters work? I tried to googled but without success so that's why I am asking here. One more thing... is there a list about the values that corresponds on certain rc5_device. I think source says something like 1-31 0-31, the general allocation is listed at [1] but that doesn't really help. If you want to know for sure which rc5_device code your remote uses, you'll have to look at the ir_debug output messages (or experiment). I have changed this ir_debug=1 in the source file but I can't see this module messages in dmesg. From what you've said previously it seems unlikely that the module is even loaded. [1] http://www.sbprojects.com/knowledge/ir/rc5.htm -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [PATCH] Implement repeat key handling in budget-ci IR
On Sun, February 25, 2007 19:20, Oliver Endriss said: > Jouni wrote: >> During make I get this: >> >> /usr/local/src/v4ltesti/v4l-dvb/v4l/budget-ci.c:110: error: expected >> identifier before numeric constant >> make[3]: *** [/usr/local/src/v4ltesti/v4l-dvb/v4l/budget-ci.o] Error 1 >> make[2]: *** [_module_/usr/local/src/v4ltesti/v4l-dvb/v4l] Error 2 >> make[2]: Leaving directory `/usr/src/linux-headers-2.6.17-50-generic' >> make[1]: *** [default] Virhe 2 >> make[1]: Poistutaan hakemistosta "/usr/local/src/v4ltesti/v4l-dvb/v4l" >> make: *** [all] Virhe 2 >> >> Did I botch something or is there a glitch in the code? > > Does the attached patch fix it for you? > > @David: > This kind of stuff should go to compat.h anyway. > Fortunately, false/true are already defined there. ;-) Thanks for fixing the breakage, I was at FOSDEM this weekend so I did not have time to take care of it myself. The good news is of course that all drivers are free to use the bool type now. -- David Härdeman ___ 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 & (
Re: [linux-dvb] No IR-remote events with new budget_ci?
On Tue, Feb 13, 2007 at 06:30:21PM +, Darren Salt wrote: I demand that Jouni may or may not have written... [snip] I am using a learning remote, which has same numpad keys and some other keys as the one bundled with the card. And I also collected some additional commands from other rc5(Philips)-remotes, so that all available keys had a sensible key-event. But now this driver set has different key-codes (?), so all but numkeys have changed names. If with the original remote control that is the case, then there's a bug (and the card's PCI ID is needed so that it can be fixed). Would it be the best solution for me to make a custom ir-keymaps.c? Given your use of Philips remote controls too, I'd say so. I would recommend that you use input-kbd from input-utils to create a custom keymap and load it each time your machine boots. This way you won't have to change any sources and you'll be sure that it will keep on working (I use input-kbd to set keymaps with my learning remote). If you're unsure how to do it, I could write something up later this week. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] budget-ci IR handling fixups
On Tue, February 13, 2007 6:29, Oliver Endriss said: > Well, it might be better but it is not correct yet. ;-) > ... > For a long keypress the driver must produce '1-2-2-2-2-...-2-0' Key > events (Reset events omitted). I know that. The driver has never gotten this right (neither in the old version, the current one or the current one plus this patch). Fixing the repeat event handling (and removing the entire debounce logic which I suspect was just a way of papering over some of the bugs in the driver) is on my todo-list, but it is an issue which is orthogonal to the one addressed by the patch. At the moment, the driver doesn't work at all, so please apply this patch and I'll take a look at repeat handling later. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] budget-ci IR handling fixups
On Sun, Feb 11, 2007 at 06:48:27AM +0100, Oliver Endriss wrote: David Härdeman wrote: Changeset 6562d27de0d7 [1] by Oliver Endriss changed the budget-ci driver to use interrupt mode for i2c transfers. This also meant that a new bunch of IR bytes that were previously lost are now received, which allowed me to better understand how the MSP430 chip works. Unfortunately it also means that the current driver gets some assumptions wrong and might generate double keypresses for one IR command. The attached patch fixes this by throwing away the repeat bytes and by associating the correct command and device bytes. Please apply. Since I am not able to test the patch, I'd like to verify that the patched driver creates correct input events. I wrote the old IR handling code that is currently in the unpatched driver (based on the work of Darren Salt). I've already verified on my own MythTV box that the patched driver does the right thing. Without the patch, the IR handling doesn't work at all or creates repeated events at the moment. Would you please post the output of the evtest tool for - a short key press (no key repeat) Input driver version is 1.0.0 Input device ID: bus 0x1 vendor 0x13c2 product 0x1010 version 0x1 Input device name: "Budget-CI dvb ir receiver saa7146 (0)" Supported events: Event type 0 (Reset) Event code 0 (Reset) Event code 1 (Key) Event type 1 (Key) Event code 0 (Reserved) Event code 1 (Esc) Event code 2 (1) Event code 109 (PageDown) Event code 116 (Power) Testing ... (interrupt to exit) Event: time 1171327747.288858, type 1 (Key), code 106 (Right), value 1 Event: time 1171327747.288862, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327747.288864, type 1 (Key), code 106 (Right), value 0 Event: time 1171327747.288864, type 0 (Reset), code 0 (Reset), value 0 - a long key press (key repeat) Event: time 1171327812.339208, type 1 (Key), code 103 (Up), value 1 Event: time 1171327812.339213, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327812.339214, type 1 (Key), code 103 (Up), value 0 Event: time 1171327812.339214, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327812.544223, type 1 (Key), code 103 (Up), value 1 Event: time 1171327812.544228, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327812.544229, type 1 (Key), code 103 (Up), value 0 Event: time 1171327812.544232, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327812.760376, type 1 (Key), code 103 (Up), value 1 Event: time 1171327812.760378, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327812.760381, type 1 (Key), code 103 (Up), value 0 Event: time 1171327812.760382, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327812.932262, type 1 (Key), code 103 (Up), value 1 Event: time 1171327812.932264, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327812.932268, type 1 (Key), code 103 (Up), value 0 Event: time 1171327812.932269, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327813.167067, type 1 (Key), code 103 (Up), value 1 Event: time 1171327813.167069, type 0 (Reset), code 0 (Reset), value 0 Event: time 1171327813.167073, type 1 (Key), code 103 (Up), value 0 Event: time 1171327813.167073, type 0 (Reset), code 0 (Reset), value 0 I don't think you even want to see the evtest output when running with the unpatched driver :) Furthermore, there's already two users on-list (not counting myself) who have been helped by the patch, so I think you can feel safe in applying it. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] No IR-remote events with new budget_ci?
On Mon, Feb 12, 2007 at 11:51:26PM +0200, Jouni wrote: Thanks for the tip! Now, by actually using 'ir_debug' ;) , I am able to get dmesgs showing bunch of "budget_ci: received byte 0x..."'s per one keypress. Still did not find a rc5_device number that would produce keypress events (besides some random "generating keypress"), tried with unpatched and patched code. Are you using the remote that was sold with the card or some other remote? Looking at the dmesg you posted, I think the rc5_device number of your remote is 5, so could you try loading the module with "rc5_device=5 ir_debug=1" and alternatively with "rc5_device=255 ir_debug=1". Should that not work, then you could also try the same two alternatives but with ir_debug=0 since the extra printk's can cause the driver to lose some events. On Mon, 12 Feb 2007 19:50:41 +0200 (EET), "Teemu Suikki" <[EMAIL PROTECTED]> said: I have the same card and same driver versions, and it works for me. However, I think that the rc5 autodetect is somehow broken. I manually tried with different rc5_device parameters until it worked. I'm using a different remote (not the technotrend one) so my rc5_device probably is not the same as the original anyway.. But it didn't work with autodetect. The word "autodetect" might be a bit misleading. It's rather that it is set to a default value based on which card you have (in your case that would mean that it is set to the rc5_device of the original remote). If you want the card to listen to any rc5 code, use rc5_device=255 as a parameter (note though that it may then pick up unrelated commands from other remote controls if they are also rc5). Or you can do as Jouni and load the driver with ir_debug, then press a few buttons, and then look in dmesg for bytes with a value in the range 0 - 31 (0x00 - 0x1f), that should be your rc5_device number. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] No IR-remote events with new budget_ci?
On Tue, Feb 13, 2007 at 12:04:03AM +0200, Jouni wrote: Ok, here it is, pressed remote keys 1-2-3: The log looks fine, the driver is receiving and decoding the bytes properly. I've included an explanation below in case someone might be morbidly interested in the details: [ 1005.308387] budget_ci: received byte 0xc1 Highest bit set (crap byte) => thrown away [ 1005.338100] budget_ci: received byte 0x85 Highest bit set (crap byte) => thrown away [ 1005.365147] budget_ci: received byte 0x41 IR command 0x01 (key 1) [ 1005.388069] budget_ci: received byte 0x05 IR device 0x05 (with toggle bit not set) A keypress can now be generated [ 1007.380190] budget_ci: received byte 0xc2 Highest bit set (crap byte) => thrown away [ 1007.390605] budget_ci: received byte 0xa5 Highest bit set (crap byte) => thrown away [ 1007.436963] budget_ci: received byte 0x42 IR command 0x02 (key 2) [ 1007.440557] budget_ci: received byte 0x25 IR device 0x05 (with toggle bit set) A keypress can now be generated [ 1007.493698] budget_ci: received byte 0xc2 Highest bit set (crap byte) => thrown away [ 1007.540489] budget_ci: received byte 0xa5 Highest bit set (crap byte) => thrown away [ 1008.086744] budget_ci: received byte 0x43 IR command 0x03 (key 3) [ 1008.090097] budget_ci: received byte 0x05 IR device 0x05 (with toggle bit not set) A keypress can now be generated [ 1008.143488] budget_ci: received byte 0xc3 Highest bit set (crap byte) => thrown away [ 1008.190009] budget_ci: received byte 0x80 Highest bit set (crap byte) => thrown away [ 1008.200234] budget_ci: received byte 0x43 IR command 0x03 (key 3) [ 1008.239990] budget_ci: received byte 0x05 IR device 0x05 (with toggle bit not set) A repeat keypress can now be generated So the sequence "1-2-3-3" should have been generated (with the last "3" resulting from a long keypress). The most likely explanation is that the rc5_device does not match, could you provide me with the output from running "cat /sys/module/budget_ci/parameters/rc5_device"? -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] No IR-remote events with new budget_ci?
On Mon, Feb 12, 2007 at 06:25:53PM +0200, Jouni wrote: On Mon, 12 Feb 2007 08:39:10 +0100 (CET), "David Härdeman" <[EMAIL PROTECTED]> said: On Sun, February 11, 2007 15:13, Jouni said: I updated the DVB-modules (for improved ir handling) to recent versions from v4l-Mercurial, and now the input events stopped working. However, all initializes without errors, no lirc stuff running, and the inputs are available with 'lsinput'. But still not getting any events with 'evtest' from the cards ir-receiver. Yes, could you please try this patch: http://www.linuxtv.org/pipermail/linux-dvb/2007-February/015759.html I tried this patch, but no events on inputs. Could you try loading the budget-ci module with the parameter ir_debug=1, push a couple of buttons and then send the output from "dmesg" to the list? -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] No IR-remote events with new budget_ci?
On Sun, February 11, 2007 15:13, Jouni said: > I am using Kubuntu Edgy & Kernel 2.6.17-11-generic (AMD64/SMP). > > The default driver modules from this Kernel worked quite ok for > Technotrend T-1500's IR receiver input events (the card uses budget_ci, > saa7146, tda1004x). > > I updated the DVB-modules (for improved ir handling) to recent versions > from v4l-Mercurial, and now the input events stopped working. However, > all initializes without errors, no lirc stuff running, and the inputs > are available with 'lsinput'. But still not getting any events with > 'evtest' from the cards ir-receiver. > > Budget_ci's srcversion is 70035214582C9009995F1ED. > > Any ideas? Yes, could you please try this patch: http://www.linuxtv.org/pipermail/linux-dvb/2007-February/015759.html Please let me know if it works or not. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Casema (Netherlands) DVB-C initial scan file
Hi, here's an initial scan file for Casema (and probably some other cable companies) in the Netherlands, please add to the dvb-apps repo. Signed-off-by: David Härdeman <[EMAIL PROTECTED]> -- David Härdeman # Casema Netherlands # freq sr fec mod C 37200 6875000 NONE QAM64 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] budget-ci IR handling fixups
Changeset 6562d27de0d7 [1] by Oliver Endriss changed the budget-ci
driver to use interrupt mode for i2c transfers.
This also meant that a new bunch of IR bytes that were previously lost
are now received, which allowed me to better understand how the MSP430
chip works. Unfortunately it also means that the current driver gets
some assumptions wrong and might generate double keypresses for one IR
command.
The attached patch fixes this by throwing away the repeat bytes and by
associating the correct command and device bytes. Please apply.
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
--
David Härdeman
[1] http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=6562d27de0d7;style=gitweb
diff -r b95f02bae37f linux/drivers/media/dvb/ttpci/budget-ci.c
--- a/linux/drivers/media/dvb/ttpci/budget-ci.c Fri Feb 02 13:24:56 2007 -0200
+++ b/linux/drivers/media/dvb/ttpci/budget-ci.c Mon Feb 05 18:21:04 2007 +0100
@@ -130,6 +130,7 @@ static void msp430_ir_interrupt(unsigned
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;
/*
@@ -138,21 +139,34 @@ static void msp430_ir_interrupt(unsigned
* type1: X1CC, C = command bits (0 - 63)
* type2: X0TD, D = device bits (0 - 31), T = RC5 toggle bit
*
- * More than one command byte may be generated before the device byte
- * Only when we have both, a correct keypress is generated
+ * Each signal from the remote control can generate one or more command
+ * 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.
+ *
+ * Only when we have a command and device byte, a keypress is
+ * generated.
*/
+
+ if (ir_debug)
+ printk("budget_ci: received byte 0x%02x\n", command);
+
+ /* Is this a repeated byte? */
+ if (command & 0x80)
+ return;
/* Is this a RC5 command byte? */
if (command & 0x40) {
- if (ir_debug)
- printk("budget_ci: received command byte 0x%02x\n", command);
+ state = 1;
ir_key = command & 0x3f;
return;
}
/* It's a RC5 device byte */
- if (ir_debug)
- printk("budget_ci: received device byte 0x%02x\n", command);
+ if (!state)
+ return;
+ state = 0;
device = command & 0x1f;
toggle = command & 0x20;
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB-C card anyone?
On Sun, Jan 21, 2007 at 04:55:11PM +0100, Henrik Gammelmark wrote: Hello all A friend and myself are thinking of switching to DVB-C with MythTV instead of the standard analogue tuners we have now. We have a few questions however: - Which (PCI-based) tunercard should we choose, and why? - Does all CAMs work with all tuner cards? (we realise that the type of reader depends on the content provider) - Does MythTV require anything from the card except valid drivers? No, not really We have found a few candidates, but not sure what to look out for, and which to choose (if any of these at all): - Technotrend Budget C-1500 This is the card I use together with MythTV and a AlphaCrypt CAM module. It works fine, provided that a recent version of MythTV is used (there were a number of patches applied during the last month, some of which I wrote, which improved the AlphaCrypt support alot). Do you know which crypto system your provider uses? (it will be important for your choice of CAM module) -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Freecom DVB-T USB Stick (25451-rev.3)
On Tue, Jan 09, 2007 at 07:32:12PM +, Steve Brokenshire wrote: Hi, (Before I start... sorry if this a bit long but hopefully someone will find something useful here) Software running (on PVR): Debian 3.1 Linux kernel 2.6.19 Do you have CONFIG_USB_BANDWIDTH enabled in your kernel? ... Anyone else having problems that I'm having? Any suggestions and ideas (any other tests I should do?) are appreciated. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Cam Menu?
On Mon, Oct 30, 2006 at 08:32:27PM +0100, David Härdeman wrote: On Mon, Oct 30, 2006 at 07:07:05PM +, Andrew Lyon wrote: Really not sure what is wrong, I can leave it playing a encrypted channel for days at a time, but if I change channels a few times it stops working, I have a feeling perhaps the cam is not responding quickly enough to commands, are there any timeout values I could try changing? If you're feeling adventurous, you might try recompiling MythTV. In mythtv/libs/libmythtv/dvbcam.cpp, function DVBCam::CiHandlerLoop(), there is a usleep(250) which I suspect is way to low. The CI specification (EN50221) says it's fine to poll every 100ms, so try setting it to 9 or so (this ain't 100% correct because MythTV might still want the shorter timeout to read replies etc...but it's a start if you want to spend some effort debugging). I know this was a long time ago, but it might interest you that I got two patches committed to the MythTV repo today which improves the loop timeout, adds proper per-100ms polling and implements support for the DVB time (all in all, those patches should help you). Expect to see the new functionality in 0.21. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [av7110/budget/budget-ci/budget-av drivers] please test: drivers switched to I2C interrupt mode
On Wed, November 1, 2006 22:06, Andrew Lyon said: > Compeltely unrelated but I use this patch: > http://koti.welho.com/jkukkone/vdr/v4l-dvb_tt-1500.patch otherwise > some of the buttons on my technotrend remote do not work, I believe > the patch breaks other remotes so I dont ever expect it to be merged, > but will there ever be a better solution to the problem of different > remotes? I posted a set of patches (based on the work of Darren Salt) a couple of weeks ago which add dynamic keymaps which can be changed from userspace using the regular input-utils. I need to work a bit on the patchset and resubmit it when I have some more time. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Cam Menu?
On Mon, Oct 30, 2006 at 11:36:24PM +, Andrew Lyon wrote: On 10/30/06, David Härdeman <[EMAIL PROTECTED]> wrote: If you're feeling adventurous, you might try recompiling MythTV. In mythtv/libs/libmythtv/dvbcam.cpp, function DVBCam::CiHandlerLoop(), there is a usleep(250) which I suspect is way to low. The CI specification (EN50221) says it's fine to poll every 100ms, so try setting it to 9 or so (this ain't 100% correct because MythTV might still want the shorter timeout to read replies etc...but it's a start if you want to spend some effort debugging). Wow!, changing usleep to 9 seems to have completely fixed the problem :), Ive changed channel over and over again and even by entering channel numbers really quickly I cannot make it fail. The channel change time seems the same too, I will see how it goes in the next few days and report back again. Thanks for your suggestion, didnt it work as well for you? Not completely...but it improved things. I think the cable might be dodgy so I'm arranging to get a new one (long story). -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Cam Menu?
On Mon, Oct 30, 2006 at 07:07:05PM +, Andrew Lyon wrote: On Mon, Oct 30, 2006 at 04:19:09PM +, Andrew Lyon wrote: Also make sure you use recent drivers from the dvb repo, a patch I wrote was committed a day or two ago, and without it, my CAM would lock up by simply using a remote control (which would in turn produce lots of interesting error messages). I am using a Technotrend S-1500 + CI + CAM, Ive not had errors when using the remote, but I do get problems with my card/cam if I change channels too quickly, and sometimes if i just leave myth running in the main menu, when I watch tv it always gets lock, but I get a blank screen for a long time and eventually a video error or I have to kill mythfrontend, stopping the backend, removing and reloading budget_ci and restarting the backend usually cures it, I ended up adding a menu item for that but its not a nice solution :(. I have more or less the same problems. I spent some time last week debugging it but I didn't get that far. Really not sure what is wrong, I can leave it playing a encrypted channel for days at a time, but if I change channels a few times it stops working, I have a feeling perhaps the cam is not responding quickly enough to commands, are there any timeout values I could try changing? If you're feeling adventurous, you might try recompiling MythTV. In mythtv/libs/libmythtv/dvbcam.cpp, function DVBCam::CiHandlerLoop(), there is a usleep(250) which I suspect is way to low. The CI specification (EN50221) says it's fine to poll every 100ms, so try setting it to 9 or so (this ain't 100% correct because MythTV might still want the shorter timeout to read replies etc...but it's a start if you want to spend some effort debugging). Additionally, you might want to change mythtv/libs/libmythtv/dvbdev/dvbci.cpp, find the line in the beginning that says: static bool DebugProtocol = false; and change it to static bool DebugProtocol = true; which will give you much more debug info if/when the card acts up. My dvb-s card (Avermedia 777) and Freeview channels do not have the same problem. It seems very dependent on the CAM that you're using. I'm using an AlphaCrypt with 3.09 firmware, which seems extremely picky. For instance, I was earlier using an extra long cable to connect the CI board with the C-1500 board, and that caused constant lockups and errors (within seconds, cammenu was barely useable) and things improved when I used the original (shorter) cable again. I'm going to spend more time debugging my C-1500 when I have some more time to spend :) -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Cam Menu?
On Mon, Oct 30, 2006 at 04:19:09PM +, Andrew Lyon wrote: On Sat, Oct 28, 2006 at 07:09:32PM +0100, Andrew Lyon wrote: >Is there any util I can use with Technotrend S-1500 with CI to get >into the cam menu? The cam has settings that I need to change, >apparently with a set top box you can go into the cam menu, but I >cannot find any way with a dvb card on linux. Try the "gnutv" app from the dvb-apps repo using the "-cammenu" option -- David Härdeman Does that work for you? Yup (using a C-1500) # dmesg | grep frontend DVB: registering frontend 0 (Zarlink MT352 DVB-T)... DVB: registering frontend 1 (ST STV0299 DVB-S)... so I use adapter 1 : # gnutv -cammenu -adapter 1 en50221_tl_handle_sb: Received T_SB for connection not in T_STATE_ACTIVE from module on slot 00 en50221_stdcam_llci_poll: Error reported by stack:-7 en50221_tl_poll: CAWrite failed en50221_stdcam_llci_poll: Error reported by stack:-2 mythbackend had been running (and using that adapter) but I stopped it before running gnutv. I'd suggest you try it again after a reboot or after unloading/reloading the budget-ci module, it seems the CAM module was still active after Myth had been using it. Also make sure you use recent drivers from the dvb repo, a patch I wrote was committed a day or two ago, and without it, my CAM would lock up by simply using a remote control (which would in turn produce lots of interesting error messages). -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Cam Menu?
On Sat, Oct 28, 2006 at 07:09:32PM +0100, Andrew Lyon wrote: Is there any util I can use with Technotrend S-1500 with CI to get into the cam menu? The cam has settings that I need to change, apparently with a set top box you can go into the cam menu, but I cannot find any way with a dvb card on linux. Try the "gnutv" app from the dvb-apps repo using the "-cammenu" option -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] budget-ci: Change DEBIADDR_IR to a safer default
The IR chip has no address decoding, so the IR data is always present in the high byte when doing a read from the saa7146 chip. This means that the DEBI address used is irrelevant to the IR decoding logic. DEBI addresses 0x1XXX are mapped to the registers on the CI module itself, but only the lowest two bits are actually used (see EN50221, section A.2.2.1), meaning that 0x1234 is equivalent to 0x1000 which maps to register 0 (the data register). A read from the data register is supposed to be preceded by a read from the size register, so some CI modules will be confused (the AlphaCrypt CAM will hang completely). The attached patch changes the address used when reading the IR data to use 0x4000 instead. This is the CI version address, which is a safer default, works with the AlphaCrypt CAM and matches the behaviour of the Windows driver (AFAIK). Please apply to the dvb repo. Signed-off-by: David Härdeman <[EMAIL PROTECTED]> diff -ur v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c --- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-25 22:26:21.0 +0200 +++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-26 17:43:07.0 +0200 @@ -46,7 +46,14 @@ #include "bsbe1.h" #include "bsru6.h" -#define DEBIADDR_IR0x1234 +/* + * Regarding DEBIADDR_IR: + * Some CI modules hang if random addresses are read. + * Using address 0x4000 for the IR read means that we + * use the same address as for CI version, which should + * be a safe default. + */ +#define DEBIADDR_IR0x4000 #define DEBIADDR_CICONTROL 0x #define DEBIADDR_CIVERSION 0x4000 #define DEBIADDR_IO0x1000 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] budget-ci: IR interrupt disabling CI module?
On Thu, Oct 26, 2006 at 10:56:49AM +0200, David Härdeman wrote: On Thu, October 26, 2006 2:16, David Härdeman said: I'm currently trying to get a TechnoTrend C-1500 Budget card (using the budget-ci module), using a CAM module, working with MythTV. After some debugging it seems that it does work fine until I use the remote, so if I control MythTV using a regular keyboard...I am able to watch channels as normal...but as soon as I push any button on the remote, the CI communication dies. It seems that the windows drivers use the 0x4000 address for the IR read, which reads the CI hardware version number instead. Perhaps this is a safer default. I'll try this approach this evening and see if it helps... Using 0x4000 instead of 0x1234 as the DEBI address works perfectly. Using the remote no longer hangs my CI module, I'll post a patch in a separate mail. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] budget-ci: IR interrupt disabling CI module?
On Thu, October 26, 2006 2:16, David Härdeman said: > I'm currently trying to get a TechnoTrend C-1500 Budget card (using the > budget-ci module), using a CAM module, working with MythTV. > > After some debugging it seems that it does work fine until I use the > remote, so if I control MythTV using a regular keyboard...I am able to > watch channels as normal...but as soon as I push any button on the > remote, the CI communication dies. Looking further at the datasheets and the source, it seems that DEBI address 0x1234 is used when reading the IR command. The address in itself is quite irrelevant as the IR module has no address decoding so the IR data will always be present in the high bytes. However, 0x1XXX addresses are mapped to the registers on the CI module, and since it only uses the lowest two address bits (see EN50221, section A.2.2.1), 0x1234 will map to register 0 which is the data register. Reading from the data register is supposed to be preceded by a read from the size register, which potentially confuses the CAM (I'm using an AlpaCrypt CAM, fw version 3.09). It seems that the windows drivers use the 0x4000 address for the IR read, which reads the CI hardware version number instead. Perhaps this is a safer default. I'll try this approach this evening and see if it helps... -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] budget-ci: IR interrupt disabling CI module?
I'm currently trying to get a TechnoTrend C-1500 Budget card (using the budget-ci module), using a CAM module, working with MythTV. After some debugging it seems that it does work fine until I use the remote, so if I control MythTV using a regular keyboard...I am able to watch channels as normal...but as soon as I push any button on the remote, the CI communication dies. I'm using modules built from sources pulled from the hg repo today. The debugging output from MythTV is included below. In addition, I've verified that the same problem appears when using gnutv from the dvb-apps repo, which starts to spit out "en50221_stdcam_llci_poll: Error reported by stack:-3" after the first IR interrupt has been generated. Now, if this is really a bug in the budget-ci module, I'm surprised that noone else has experienced it. So I'm hoping to get some feedback here cause I'm at a loss to figure out what is going on... -- David Härdeman MythTV debug output: 2006-10-25 22:34:27.606 Using runtime prefix = /usr 2006-10-25 22:34:27.743 New DB connection, total: 1 2006-10-25 22:34:27.775 Connected to database 'mythconverg' at host: localhost 2006-10-25 22:34:27.781 Current Schema Version: 1160 Starting up as the master server. 2006-10-25 22:34:27.907 New DB connection, total: 2 2006-10-25 22:34:27.917 Connected to database 'mythconverg' at host: localhost 2006-10-25 22:34:27.932 EITHelper: localtime offset 2:00:00 Resetting slot 0...ok. 2006-10-25 22:34:28.156 New DB connection, total: 3 2006-10-25 22:34:28.158 Connected to database 'mythconverg' at host: localhost 2006-10-25 22:34:28.260 DVBTuning Warning: Invalid inversion, aborting, falling back to 'auto' 2006-10-25 22:34:28.354 New DB scheduler connection Module ready in slot 0 Creating connection: slot 0, tcid 1 --> 00 01 82 01 01 2006-10-25 22:34:28.381 Connected to database 'mythconverg' at host: localhost <-- 00 01 83 01 01 80 02 01 00 . . . . . . . . . 2006-10-25 22:34:28.398 Main::Starting HttpServer 2006-10-25 22:34:28.462 Main::Registering HttpStatus Extension 2006-10-25 22:34:28.510 mythbackend version: 0.20.20060828-3 www.mythtv.org 2006-10-25 22:34:28.525 Enabled verbose msgs: important general --> 00 01 A0 01 01 <-- 00 01 80 02 01 80 . . . . . . --> 00 01 81 01 01 2006-10-25 22:34:28.588 AutoExpire: Found 1 recorders w/max rate of 138 MiB/min 2006-10-25 22:34:28.643 AutoExpire: Required Free Space: 3.0 GB w/freq: 10 min <-- 00 01 A0 07 01 91 04 00 01 00 41 80 02 01 00 . . . . . . . . . . A . . . . OpenSession 00010041 New Resource Manager (session id 1) --> 00 01 A0 0A 01 92 07 00 00 01 00 41 00 01 <-- 00 01 80 02 01 00 . . . . . . 1: ==> Profile Enq --> 00 01 A0 09 01 90 02 00 01 9F 80 10 00 <-- 00 01 80 02 01 00 . . . . . . --> 00 01 A0 01 01 <-- 00 01 80 02 01 80 . . . . . . --> 00 01 81 01 01 <-- 00 01 A0 82 00 09 01 90 02 00 01 9F 80 11 00 80 02 01 00 . . . . . . . . . . . . . . . . . . . 1: <== Profile 1: ==> Profile Change --> 00 01 A0 09 01 90 02 00 01 9F 80 12 00 <-- 00 01 80 02 01 00 . . . . . . --> 00 01 A0 01 01 <-- 00 01 80 02 01 80 . . . . . . --> 00 01 81 01 01 <-- 00 01 A0 82 00 09 01 90 02 00 01 9F 80 10 00 80 02 01 00 . . . . . . . . . . . . . . . . . . . 1: <== Profile Enquiry 1: ==> Profile --> 00 01 A0 1D 01 90 02 00 01 9F 80 11 14 00 01 00 41 00 02 00 41 00 03 00 41 00 24 00 41 00 40 00 41 <-- 00 01 80 02 01 00 . . . . . . --> 00 01 A0 01 01 <-- 00 01 80 02 01 80 . . . . . . --> 00 01 81 01 01 <-- 00 01 A0 07 01 91 04 00 02 00 41 80 02 01 00 . . . . . . . . . . A . . . . OpenSession 00020041 New Application Information (session id 2) --> 00 01 A0 0A 01 92 07 00 00 02 00 41 00 02 2006-10-25 22:34:30.399 Reschedule requested for id -1. <-- 00 01 80 02 01 00 . . . . . . 2: ==> Application Info Enq --> 00 01 A0 09 01 90 02 00 02 9F 80 20 00 2006-10-25 22:34:31.092 Scheduled 0 items in 0.7 = 0.64 match + 0.05 place <-- 00 01 80 02 01 80 . . . . . . 2006-10-25 22:34:31.222 Seem to be woken up by USER --> 00 01 81 01 01 <-- 00 01 A0 07 01 91 04 00 03 00 41 80 02 01 00 . . . . . . . . . . A . . . . OpenSession 00030041 New Conditional Access Support (session id 3) --> 00 01 A0 0A 01 92 07 00 00 03 00 41 00 03 <-- 00 01 80 02 01 80 . . . . . . 3: ==> Ca Info Enq --> 00 01 A0 09 01 90 02 00 03 9F 80 30 00 <-- 00 01 80 02 01 00 . . . . . . --> 00 01 A0 01 01 <-- 00 01 80 02 01 00 . . . . . . --> 00 01 A0 01 01 <-- 00 01 80 02 01 00 . . . . . . --> 00 01 A0 01 01 <-- 00 01 80 02 01 00
[linux-dvb] Getting patches applied?
A week ago I sent a couple of patches to the list for improving the budget-ci ir handling. I haven't received any comments on the patches themselves (negative or positive), but private mails from two persons who tried the patches successfully. Now, should I have CC:ed someone in particular in order to have the patches committed to the repo, did anyone experience problems with them or should I just be more patient? -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch 0/8] budget_ci: improve IR input handling
On Wed, October 4, 2006 12:53, Oliver Endriss said: > David Härdeman wrote: >> On Wed, October 4, 2006 10:44, Torgeir Veimo said: >>> Well I run an application without X while taking input only using the >>> linux input system, and I'm still having problems with multiple input >>> when pressing a single key. And I don't have LIRC installed. I've >>> heard from multiple sources that there are problems with the driver >>> code that handles the RC5 reception. >> >> Oh, I see. Then there is in fact a bug in the av7110 IR handling. > > Afaik the av7110 ir driver works correctly. > > As I wrote before: > If an application reads from the keyboard _and_ /dev/input/eventX at > the same time, it will see all keypresses twice (unless it grabs the > input device using EVIOCGRAB). I assumed from "taking input only using the linux input system" that the application did just that. One way of testing where the problem lies would be to run "input-event " where num is the number of the event device corresponding to the ir remote. Check the output when pressing one key on the remote, if one keypress (and release) is generated, the driver is working as expected and something else (e.g. the application) is at fault... And I'll stop commenting on the av7110 driver now since it's not on my radar. -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch 0/8] budget_ci: improve IR input handling
On Wed, October 4, 2006 10:44, Torgeir Veimo said: > On 4 Oct 2006, at 08:35, David Härdeman wrote: >> The solution is simple, get rid of LIRC > > Well I run an application without X while taking input only using the > linux input system, and I'm still having problems with multiple input > when pressing a single key. And I don't have LIRC installed. I've > heard from multiple sources that there are problems with the driver > code that handles the RC5 reception. Oh, I see. Then there is in fact a bug in the av7110 IR handling. However, my patches are against the budget-ci driver, so it's not really my problem (don't have the hardware so I can't do any real testing or patchingbut the debounce logic could probably be changed in similar ways in that driver as my patches do to the budget-ci driver...don't know if it would help though). I'd still appreciate tests from others using the budget-ci driver with the patches I've posted. And I still think people should stop using LIRC when possible :) -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch 0/8] budget_ci: improve IR input handling
On Wed, October 4, 2006 1:20, Oliver Endriss said: > Torgeir Veimo wrote: >> Those double keypress issues are also present when using the linux >> input system, it's not LIRC dependent at all. ... > Solution: > The application must grab the input device for exclusive access. > In other words: Get LIRC fixed. ;-) No, the proper solution is to get rid of LIRC altogether, just use the input subsystem - it is a much saner solution (and I say this as someone who has written patches for LIRC in the past). If any of your favourite apps don't support mapping arbitrary keys to actions, file a bug report against that app (MythTV, Xine, Mplayer, Xmame all support mapping keys). -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch 0/8] budget_ci: improve IR input handling
On Tue, October 3, 2006 22:43, C.Y.M said: > David Härdeman wrote: >> I'm sorry, but I don't quite follow...the ir driver for the av7110 uses >> the Linux input system (i.e. appears as a keyboard more or less), why >> use >> LIRC? Exactly what issues do you have? > > If I want to use Mythtv with the Nexus-S, then I have to use LIRC. But, > everyone that I talk to with a hauppauge card seems to have a "double key > press" > problem when trying to use LIRC with those built in IR sensors. No, you *do not* need to use LIRC with MythTV. I control MythTV, Xine, Mplayer and Xmame with a remote without using LIRC. The problem, you're experiencing is that the keypresses are reported as such from the input subsystem, the X server sees them as keyboard input and passes them to the program. At the same time, LIRC passes the events as IR events to the same programergo, two actions for one keypress. The solution is simple, get rid of LIRC Oh, and your email address bounces... -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch 0/8] budget_ci: improve IR input handling
On Tue, October 3, 2006 2:33, C.Y.M said: > David Härdeman wrote: >> This series of patches includes a number of bugfixes and changes to the >> IR input handling of the budget-ci driver. > > If these patches are successful, can they also be implemented into the > regular nexus-s ir drivers too? Which driver is that? av7110? > I have the same lirc issues with my full featured > nexus card as others do with hauppauge budget cards. I'm sorry, but I don't quite follow...the ir driver for the av7110 uses the Linux input system (i.e. appears as a keyboard more or less), why use LIRC? Exactly what issues do you have? -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [patch 6/8] budget-ci IR: decode rc5 device byte
Decode the RC5 device byte as well as the command byte. Introduce a
parameter to set the device events to listen for. Default to try
to auto-detect the proper device code, otherwise, listen to any
device as the old code did.
Based on Darren Salt's dvb-ir patchset.
Signed-off-by: Darren Salt <[EMAIL PROTECTED]>
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
Index: v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
18:49:03.0 +0200
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
18:49:10.0 +0200
@@ -71,6 +71,9 @@
*/
#define IR_REPEAT_TIMEOUT 350
+/* 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
*/
@@ -78,12 +81,17 @@
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);
+MODULE_PARM_DESC(rc5_device, "only IR commands to given RC5 device (device = 0
- 31, any device = 255, default: autodetect)");
+
struct budget_ci_ir {
struct input_dev *dev;
struct tasklet_struct msp430_irq_tasklet;
char name[72]; /* 40 + 32 for (struct saa7146_dev).name */
char phys[32];
struct ir_input_state state;
+ int rc5_device;
};
struct budget_ci {
@@ -107,32 +115,56 @@
struct budget_ci *budget_ci = (struct budget_ci *) data;
struct input_dev *dev = budget_ci->ir.dev;
static int bounces = 0;
- u32 ir_key;
+ int device;
+ int toggle;
+ static int prev_toggle = -1;
+ static u32 ir_key;
u32 command = ttpci_budget_debiread(&budget_ci->budget, DEBINOSWAP,
DEBIADDR_IR, 2, 1, 0) >> 8;
+ /*
+* The msp430 chip can generate two different bytes, command and device
+*
+* type1: X1CC, C = command bits (0 - 63)
+* type2: X0TD, D = device bits (0 - 31), T = RC5 toggle bit
+*
+* More than one command byte may be generated before the device byte
+* Only when we have both, a correct keypress is generated
+*/
+
+ /* Is this a RC5 command byte? */
if (command & 0x40) {
ir_key = command & 0x3f;
+ return;
+ }
- if (ir_key != dev->repeat_key && del_timer(&dev->timer))
- /* We were still waiting for a keyup event but this is
a new key */
- ir_input_nokey(dev, &budget_ci->ir.state);
-
- if (ir_key == dev->repeat_key && bounces > 0 &&
timer_pending(&dev->timer)) {
- /* Ignore repeated key sequences if requested */
- bounces--;
- return;
- }
+ /* It's a RC5 device byte */
+ device = command & 0x1f;
+ toggle = command & 0x20;
- if (!timer_pending(&dev->timer))
- /* New keypress */
- bounces = debounce;
+ if (budget_ci->ir.rc5_device != IR_DEVICE_ANY &&
budget_ci->ir.rc5_device != device)
+ return;
- /* Prepare a keyup event sometime in the future */
- mod_timer(&dev->timer, jiffies +
msecs_to_jiffies(IR_REPEAT_TIMEOUT));
+ /* Are we still waiting for a keyup event while this is a new key? */
+ if ((ir_key != dev->repeat_key || toggle != prev_toggle) &&
del_timer(&dev->timer))
+ ir_input_nokey(dev, &budget_ci->ir.state);
- /* Generate a new or repeated keypress */
- ir_input_keydown(dev, &budget_ci->ir.state, ir_key, command);
+ prev_toggle = toggle;
+
+ /* Ignore repeated key sequences if requested */
+ if (ir_key == dev->repeat_key && bounces > 0 &&
timer_pending(&dev->timer)) {
+ bounces--;
+ return;
}
+
+ /* New keypress? */
+ if (!timer_pending(&dev->timer))
+ bounces = debounce;
+
+ /* Prepare a keyup event sometime in the future */
+ mod_timer(&dev->timer, jiffies + msecs_to_jiffies(IR_REPEAT_TIMEOUT));
+
+ /* Generate a new or repeated keypress */
+ ir_input_keydown(dev, &budget_ci->ir.state, ir_key, ((device << 8) |
command));
}
static int msp430_ir_init(struct budget_ci *budget_ci)
@@ -175,7 +207,7 @@
# endif
#endif
- /* Select keymap */
+ /* Select keymap and address */
switch (bud
[linux-dvb] [patch 4/8] budget-ci IR: be more verbose in case of init failure
Trivial change to help the user understand what went wrong.
Taken from Darren Salt's dvb-ir patchset.
Signed-off-by: Darren Salt <[EMAIL PROTECTED]>
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
Index: v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
19:10:06.0 +0200
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
19:22:13.0 +0200
@@ -198,6 +198,7 @@
budget_ci->ir.dev = input_dev = input_allocate_device();
if (!input_dev) {
+ printk(KERN_ERR "budget_ci: IR interface initialisation
failed\n");
error = -ENOMEM;
goto out1;
}
@@ -1123,7 +1124,7 @@
struct budget_ci *budget_ci;
int err;
- budget_ci = kmalloc(sizeof(struct budget_ci), GFP_KERNEL);
+ budget_ci = kzalloc(sizeof(struct budget_ci), GFP_KERNEL);
if (!budget_ci) {
err = -ENOMEM;
goto out1;
@@ -1131,8 +1132,6 @@
dprintk(2, "budget_ci: %p\n", budget_ci);
- budget_ci->budget.ci_present = 0;
-
dev->ext_priv = budget_ci;
err = ttpci_budget_init(&budget_ci->budget, dev, info, THIS_MODULE);
--
David Härdeman
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [patch 3/8] budget-ci IR: improve error checking in init and deinit functions
Improve the error checking in the IR init and deinit functions.
Based on Darren Salt's dvb-ir patchset.
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
Index: v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
02:00:18.0 +0200
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
17:54:29.0 +0200
@@ -192,10 +192,15 @@
struct saa7146_dev *saa = budget_ci->budget.dev;
struct input_dev *input_dev = budget_ci->ir.dev;
int i;
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,15)
+ int error;
+#endif
budget_ci->ir.dev = input_dev = input_allocate_device();
- if (!input_dev)
- return -ENOMEM;
+ if (!input_dev) {
+ error = -ENOMEM;
+ goto out1;
+ }
snprintf(budget_ci->ir.name, sizeof(budget_ci->ir.name),
"Budget-CI dvb ir receiver %s", saa->name);
@@ -227,14 +232,30 @@
if (key_map[i])
set_bit(key_map[i], input_dev->keybit);
- input_register_device(budget_ci->ir.dev);
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,15)
+ error = input_register_device(input_dev);
+ if (error) {
+ printk(KERN_ERR "budget_ci: could not init driver for IR device
(code %d)\n", error);
+ goto out2;
+ }
+#else
+ input_register_device(input_dev);
+#endif
input_dev->timer.function = msp430_ir_debounce;
+ tasklet_init(&budget_ci->ir.msp430_irq_tasklet, msp430_ir_interrupt,
+(unsigned long) budget_ci);
+
saa7146_write(saa, IER, saa7146_read(saa, IER) | MASK_06);
saa7146_setgpio(saa, 3, SAA7146_GPIO_IRQHI);
return 0;
+
+out2:
+ input_free_device(input_dev);
+out1:
+ return error;
}
static void msp430_ir_deinit(struct budget_ci *budget_ci)
@@ -244,6 +265,7 @@
saa7146_write(saa, IER, saa7146_read(saa, IER) & ~MASK_06);
saa7146_setgpio(saa, 3, SAA7146_GPIO_INPUT);
+ tasklet_kill(&budget_ci->ir.msp430_irq_tasklet);
if (del_timer(&dev->timer))
input_event(dev, EV_KEY, key_map[dev->repeat_key], !!0);
@@ -1101,8 +1123,11 @@
struct budget_ci *budget_ci;
int err;
- if (!(budget_ci = kmalloc(sizeof(struct budget_ci), GFP_KERNEL)))
- return -ENOMEM;
+ budget_ci = kmalloc(sizeof(struct budget_ci), GFP_KERNEL);
+ if (!budget_ci) {
+ err = -ENOMEM;
+ goto out1;
+ }
dprintk(2, "budget_ci: %p\n", budget_ci);
@@ -1110,15 +1135,13 @@
dev->ext_priv = budget_ci;
- if ((err = ttpci_budget_init(&budget_ci->budget, dev, info,
THIS_MODULE))) {
- kfree(budget_ci);
- return err;
- }
-
- tasklet_init(&budget_ci->ir.msp430_irq_tasklet, msp430_ir_interrupt,
-(unsigned long) budget_ci);
-
- msp430_ir_init(budget_ci);
+ err = ttpci_budget_init(&budget_ci->budget, dev, info, THIS_MODULE);
+ if (err)
+ goto out2;
+
+ err = msp430_ir_init(budget_ci);
+ if (err)
+ goto out3;
ciintf_init(budget_ci);
@@ -1128,6 +1151,13 @@
ttpci_budget_init_hooks(&budget_ci->budget);
return 0;
+
+out3:
+ ttpci_budget_deinit(&budget_ci->budget);
+out2:
+ kfree(budget_ci);
+out1:
+ return err;
}
static int budget_ci_detach(struct saa7146_dev *dev)
@@ -1138,16 +1168,13 @@
if (budget_ci->budget.ci_present)
ciintf_deinit(budget_ci);
+ msp430_ir_deinit(budget_ci);
if (budget_ci->budget.dvb_frontend) {
dvb_unregister_frontend(budget_ci->budget.dvb_frontend);
dvb_frontend_detach(budget_ci->budget.dvb_frontend);
}
err = ttpci_budget_deinit(&budget_ci->budget);
- tasklet_kill(&budget_ci->ir.msp430_irq_tasklet);
-
- msp430_ir_deinit(budget_ci);
-
// disable frontend and CI interface
saa7146_setgpio(saa, 2, SAA7146_GPIO_INPUT);
--
David Härdeman
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [patch 2/8] budget-ci IR: support EVIOCGPHYS
This patch adds a 'phys' string, of the same form as used by various other
DVB cards' IR drivers, for access by any program which uses the EVIOCPHYS
ioctl or may read /sys/class/input/*/phys (e.g. udev) to identify input
device nodes.
Taken from Darren Salt's dvb-ir patchset.
Signed-off-by: Darren Salt <[EMAIL PROTECTED]>
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
Index: v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
01:59:42.0 +0200
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
17:54:31.0 +0200
@@ -69,6 +69,7 @@
struct input_dev *dev;
struct tasklet_struct msp430_irq_tasklet;
char name[72]; /* 40 + 32 for (struct saa7146_dev).name */
+ char phys[32];
};
struct budget_ci {
@@ -198,8 +199,29 @@
snprintf(budget_ci->ir.name, sizeof(budget_ci->ir.name),
"Budget-CI dvb ir receiver %s", saa->name);
+ snprintf(budget_ci->ir.phys, sizeof(budget_ci->ir.phys),
+"pci-%s/ir0", pci_name(saa->pci));
+
input_dev->name = budget_ci->ir.name;
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
+ input_dev->phys = budget_ci->ir.phys;
+ input_dev->id.bustype = BUS_PCI;
+ input_dev->id.version = 1;
+ if (saa->pci->subsystem_vendor) {
+ input_dev->id.vendor = saa->pci->subsystem_vendor;
+ input_dev->id.product = saa->pci->subsystem_device;
+ } else {
+ input_dev->id.vendor = saa->pci->vendor;
+ input_dev->id.product = saa->pci->device;
+ }
+# if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,15)
+ input_dev->cdev.dev = &saa->pci->dev;
+# else
+ input_dev->dev = &saa->pci->dev;
+# endif
+#endif
+
set_bit(EV_KEY, input_dev->evbit);
for (i = 0; i < ARRAY_SIZE(key_map); i++)
if (key_map[i])
--
David Härdeman
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [patch 1/8] budget-ci IR: groundwork for following patches
This patch lays down some groundwork for later budget-ci patches. The bulk
of this consists of moving a few members into a new struct and renaming a
few of them.
It also allocates extra space for the device name (the "name" field in
/proc/bus/input/devices and in the relevant sysfs dir) to avoid truncation
and uses snprintf rather than sprintf in case the extra space shouldn't be
enough.
Taken from Darren Salt's dvb-ir patchset
Signed-off-by: Darren Salt <[EMAIL PROTECTED]>
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
Index: v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
18:59:39.0 +0200
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
18:59:42.0 +0200
@@ -65,15 +65,19 @@
#define SLOTSTATUS_READY 8
#define SLOTSTATUS_OCCUPIED
(SLOTSTATUS_PRESENT|SLOTSTATUS_RESET|SLOTSTATUS_READY)
+struct budget_ci_ir {
+ struct input_dev *dev;
+ struct tasklet_struct msp430_irq_tasklet;
+ char name[72]; /* 40 + 32 for (struct saa7146_dev).name */
+};
+
struct budget_ci {
struct budget budget;
- struct input_dev *input_dev;
- struct tasklet_struct msp430_irq_tasklet;
struct tasklet_struct ciintf_irq_tasklet;
int slot_status;
int ci_irq;
struct dvb_ca_en50221 ca;
- char ir_dev_name[50];
+ struct budget_ci_ir ir;
u8 tuner_pll_address; /* used for philips_tdm1316l configs */
};
@@ -149,7 +153,7 @@
static void msp430_ir_interrupt(unsigned long data)
{
struct budget_ci *budget_ci = (struct budget_ci *) data;
- struct input_dev *dev = budget_ci->input_dev;
+ struct input_dev *dev = budget_ci->ir.dev;
unsigned int code =
ttpci_budget_debiread(&budget_ci->budget, DEBINOSWAP,
DEBIADDR_IR, 2, 1, 0) >> 8;
@@ -185,23 +189,23 @@
static int msp430_ir_init(struct budget_ci *budget_ci)
{
struct saa7146_dev *saa = budget_ci->budget.dev;
- struct input_dev *input_dev;
+ struct input_dev *input_dev = budget_ci->ir.dev;
int i;
- budget_ci->input_dev = input_dev = input_allocate_device();
+ budget_ci->ir.dev = input_dev = input_allocate_device();
if (!input_dev)
return -ENOMEM;
- sprintf(budget_ci->ir_dev_name, "Budget-CI dvb ir receiver %s",
saa->name);
-
- input_dev->name = budget_ci->ir_dev_name;
+ snprintf(budget_ci->ir.name, sizeof(budget_ci->ir.name),
+"Budget-CI dvb ir receiver %s", saa->name);
+ input_dev->name = budget_ci->ir.name;
set_bit(EV_KEY, input_dev->evbit);
for (i = 0; i < ARRAY_SIZE(key_map); i++)
if (key_map[i])
set_bit(key_map[i], input_dev->keybit);
- input_register_device(budget_ci->input_dev);
+ input_register_device(budget_ci->ir.dev);
input_dev->timer.function = msp430_ir_debounce;
@@ -214,7 +218,7 @@
static void msp430_ir_deinit(struct budget_ci *budget_ci)
{
struct saa7146_dev *saa = budget_ci->budget.dev;
- struct input_dev *dev = budget_ci->input_dev;
+ struct input_dev *dev = budget_ci->ir.dev;
saa7146_write(saa, IER, saa7146_read(saa, IER) & ~MASK_06);
saa7146_setgpio(saa, 3, SAA7146_GPIO_INPUT);
@@ -533,7 +537,7 @@
dprintk(8, "dev: %p, budget_ci: %p\n", dev, budget_ci);
if (*isr & MASK_06)
- tasklet_schedule(&budget_ci->msp430_irq_tasklet);
+ tasklet_schedule(&budget_ci->ir.msp430_irq_tasklet);
if (*isr & MASK_10)
ttpci_budget_irq10_handler(dev, isr);
@@ -1089,7 +1093,7 @@
return err;
}
- tasklet_init(&budget_ci->msp430_irq_tasklet, msp430_ir_interrupt,
+ tasklet_init(&budget_ci->ir.msp430_irq_tasklet, msp430_ir_interrupt,
(unsigned long) budget_ci);
msp430_ir_init(budget_ci);
@@ -1118,7 +1122,7 @@
}
err = ttpci_budget_deinit(&budget_ci->budget);
- tasklet_kill(&budget_ci->msp430_irq_tasklet);
+ tasklet_kill(&budget_ci->ir.msp430_irq_tasklet);
msp430_ir_deinit(budget_ci);
--
David Härdeman
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [patch 8/8] budget-ci IR: make debounce logic conditional
Change the debounce logic so that it is not used at all unless the
debounce parameter has been set. This makes for a much "snappier" remote
for most users as there is no timeout to wait for (the debounce logic has
a 350ms timer for the next repeat, but with the RC5 protocol, one event
per ~110ms is possible)
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
Index: v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
20:28:19.0 +0200
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
20:29:07.0 +0200
@@ -152,27 +152,32 @@
if (budget_ci->ir.rc5_device != IR_DEVICE_ANY &&
budget_ci->ir.rc5_device != device)
return;
- /* Are we still waiting for a keyup event while this is a new key? */
- if ((ir_key != dev->repeat_key || toggle != prev_toggle) &&
del_timer(&dev->timer))
- ir_input_nokey(dev, &budget_ci->ir.state);
-
- prev_toggle = toggle;
-
/* Ignore repeated key sequences if requested */
- if (ir_key == dev->repeat_key && bounces > 0 &&
timer_pending(&dev->timer)) {
+ 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;
- /* New keypress? */
- if (!timer_pending(&dev->timer))
- bounces = debounce;
+ /* Are we still waiting for a keyup event? */
+ if (del_timer(&dev->timer))
+ ir_input_nokey(dev, &budget_ci->ir.state);
- /* Prepare a keyup event sometime in the future */
- mod_timer(&dev->timer, jiffies + msecs_to_jiffies(IR_REPEAT_TIMEOUT));
+ /* 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)));
- /* Generate a new or repeated keypress */
- ir_input_keydown(dev, &budget_ci->ir.state, ir_key, ((device << 8) |
command));
+ /* 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);
+ }
}
static int msp430_ir_init(struct budget_ci *budget_ci)
@@ -244,11 +249,9 @@
break;
}
- /* initialise the key-up timeout handler */
+ /* initialise the key-up debounce timeout handler */
input_dev->timer.function = msp430_ir_keyup;
input_dev->timer.data = (unsigned long) &budget_ci->ir;
- input_dev->rep[REP_DELAY] = 1;
- input_dev->rep[REP_PERIOD] = 1;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,15)
error = input_register_device(input_dev);
--
David Härdeman
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [patch 7/8] budget-ci IR: add IR debugging information
This adds a ir_debug parameter which is useful in tracking down
IR decoding problems.
Based on Darren Salt's dvb-ir patchset.
Signed-off-by: Darren Salt <[EMAIL PROTECTED]>
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
Index: v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
20:44:17.0 +0200
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-03
01:10:25.0 +0200
@@ -85,6 +85,10 @@
module_param(rc5_device, int, 0644);
MODULE_PARM_DESC(rc5_device, "only IR commands to given RC5 device (device = 0
- 31, any device = 255, default: autodetect)");
+static int ir_debug = 0;
+module_param(ir_debug, int, 0644);
+MODULE_PARM_DESC(ir_debug, "enable debugging information for IR decoding");
+
struct budget_ci_ir {
struct input_dev *dev;
struct tasklet_struct msp430_irq_tasklet;
@@ -133,11 +137,15 @@
/* Is this a RC5 command byte? */
if (command & 0x40) {
+ if (ir_debug)
+ printk("budget_ci: received command byte 0x%02x\n",
command);
ir_key = command & 0x3f;
return;
}
/* It's a RC5 device byte */
+ if (ir_debug)
+ printk("budget_ci: received device byte 0x%02x\n", command);
device = command & 0x1f;
toggle = command & 0x20;
--
David Härdeman
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [patch 5/8] budget-ci IR: integrate with ir-common
This converts the budget-ci driver so that it uses ir-common for some of its
IR processing. In particular, the keymap for the Nova-T (sub 13c2:1011) is
switched to the Hauppauge grey/black keymap, of which the keys on the
supplied R808 remote control form a subset.
The old budget-ci keymap is moved to ir-keymaps.c and is used for other
remotes.
The debounce logic for buggy remotes (i.e. Zenith) is made conditional the
new debounce parameter and defaults to off (so that repeat keypresses aren't
ignored for all working remotes).
Some parts are based on Darren Salt's dvb-ir patchset.
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
Index: v4l-dvb/linux/drivers/media/common/ir-keymaps.c
===
--- v4l-dvb.orig/linux/drivers/media/common/ir-keymaps.c2006-10-02
18:48:22.0 +0200
+++ v4l-dvb/linux/drivers/media/common/ir-keymaps.c 2006-10-02
18:49:03.0 +0200
@@ -1595,3 +1595,58 @@
};
EXPORT_SYMBOL_GPL(ir_codes_norwood);
+
+/* From reading the following remotes:
+ * Zenith Universal 7 / TV Mode 807 / VCR Mode 837
+ * Hauppauge (from NOVA-CI-s box product)
+ * This is a "middle of the road" approach, differences are noted
+ */
+IR_KEYTAB_TYPE ir_codes_budget_ci_old[IR_KEYTAB_SIZE] = {
+ [ 0x00 ] = KEY_0,
+ [ 0x01 ] = KEY_1,
+ [ 0x02 ] = KEY_2,
+ [ 0x03 ] = KEY_3,
+ [ 0x04 ] = KEY_4,
+ [ 0x05 ] = KEY_5,
+ [ 0x06 ] = KEY_6,
+ [ 0x07 ] = KEY_7,
+ [ 0x08 ] = KEY_8,
+ [ 0x09 ] = KEY_9,
+ [ 0x0a ] = KEY_ENTER,
+ [ 0x0b ] = KEY_RED,
+ [ 0x0c ] = KEY_POWER, /* RADIO on Hauppauge */
+ [ 0x0d ] = KEY_MUTE,
+ [ 0x0f ] = KEY_A, /* TV on Hauppauge */
+ [ 0x10 ] = KEY_VOLUMEUP,
+ [ 0x11 ] = KEY_VOLUMEDOWN,
+ [ 0x14 ] = KEY_B,
+ [ 0x1c ] = KEY_UP,
+ [ 0x1d ] = KEY_DOWN,
+ [ 0x1e ] = KEY_OPTION,/* RESERVED on Hauppauge */
+ [ 0x1f ] = KEY_BREAK,
+ [ 0x20 ] = KEY_CHANNELUP,
+ [ 0x21 ] = KEY_CHANNELDOWN,
+ [ 0x22 ] = KEY_PREVIOUS, /* Prev. Ch on Zenith, SOURCE on
Hauppauge */
+ [ 0x24 ] = KEY_RESTART,
+ [ 0x25 ] = KEY_OK,
+ [ 0x26 ] = KEY_CYCLEWINDOWS, /* MINIMIZE on Hauppauge */
+ [ 0x28 ] = KEY_ENTER, /* VCR mode on Zenith */
+ [ 0x29 ] = KEY_PAUSE,
+ [ 0x2b ] = KEY_RIGHT,
+ [ 0x2c ] = KEY_LEFT,
+ [ 0x2e ] = KEY_MENU, /* FULL SCREEN on Hauppauge */
+ [ 0x30 ] = KEY_SLOW,
+ [ 0x31 ] = KEY_PREVIOUS, /* VCR mode on Zenith */
+ [ 0x32 ] = KEY_REWIND,
+ [ 0x34 ] = KEY_FASTFORWARD,
+ [ 0x35 ] = KEY_PLAY,
+ [ 0x36 ] = KEY_STOP,
+ [ 0x37 ] = KEY_RECORD,
+ [ 0x38 ] = KEY_TUNER, /* TV/VCR on Zenith */
+ [ 0x3a ] = KEY_C,
+ [ 0x3c ] = KEY_EXIT,
+ [ 0x3d ] = KEY_POWER2,
+ [ 0x3e ] = KEY_TUNER,
+};
+
+EXPORT_SYMBOL_GPL(ir_codes_budget_ci_old);
Index: v4l-dvb/linux/drivers/media/dvb/ttpci/Kconfig
===
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/Kconfig 2006-10-02
18:48:22.0 +0200
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/Kconfig 2006-10-02
18:49:03.0 +0200
@@ -92,6 +92,7 @@
select DVB_STV0299 if !DVB_FE_CUSTOMISE
select DVB_TDA1004X if !DVB_FE_CUSTOMISE
select DVB_LNBP21 if !DVB_FE_CUSTOMISE
+ select VIDEO_IR
help
Support for simple SAA7146 based DVB cards
(so called Budget- or Nova-PCI cards) without onboard
Index: v4l-dvb/linux/include/media/ir-common.h
===
--- v4l-dvb.orig/linux/include/media/ir-common.h2006-10-02
18:48:22.0 +0200
+++ v4l-dvb/linux/include/media/ir-common.h 2006-10-02 18:49:03.0
+0200
@@ -92,6 +92,7 @@
extern IR_KEYTAB_TYPE ir_codes_npgtech[IR_KEYTAB_SIZE];
extern IR_KEYTAB_TYPE ir_codes_norwood[IR_KEYTAB_SIZE];
extern IR_KEYTAB_TYPE ir_codes_proteus_2309[IR_KEYTAB_SIZE];
+extern IR_KEYTAB_TYPE ir_codes_budget_ci_old[IR_KEYTAB_SIZE];
#endif
Index: v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
18:48:56.0 +0200
+++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-ci.c 2006-10-02
18:49:03.0 +0200
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "dvb_ca_en50221.h"
#include "stv0299.h"
@@ -65,11 +66,24 @@
#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
+ */
+#define IR_REPEAT_TIMEOUT 350
+
[linux-dvb] [patch 0/8] budget_ci: improve IR input handling
This series of patches includes a number of bugfixes and changes to the IR input handling of the budget-ci driver. They are based on the dvb-ir patchset by Darren Salt and the two budget-ci patches that I recently sent to the list (meaning that they supercede patches 1 - 6 from Darren's series and my two previous patches). The result is a much more pleasant IR experience with snappier key reporting and some added features like RC5 device decoding. Compiled and tested with a programmable remote. Testers, comments and/or commits are welcome... -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Allow budget-ci to only listen to certain IR devices
On Thu, September 28, 2006 1:31, Darren Salt said: > http://www.youmustbejoking.demon.co.uk/progs.linux.html#dvb> > > You might like to look at them since you evidently have functioning > hardware with which you can test & debug them. Ok, I've read through the patches...and the overall direction seems to be good. I've added per-patch comments below: ... ir_01_ir-common_handle_repeat.patch Seems like a good idea. Perhaps the debounce-logic should be moved to ir-common as well since it is a problem common to all IR input drivers? ir_02_budget-ci_groundwork_and_avoid_name_truncation.patch ir_03_budget-ci_EVIOCGPHYS.patch Looks ok ir_04_budget-ci_error_and_shutdown_fixups_and_verbosity.patch No objections to the patch, two comments though: The patch reverses the order of tasklet_kill() and msp430_ir_deinit(). Are you sure that it is correct to deinit the msp430 before killing the tasklet? Nitpick: input_event(...EV_KEY...) could be changed to input_report_key() ir_05_budget-ci_kzalloc_and_more_verbosity.patch Looks ok ir_06_budget-ci_use_ir-common_and_RC5_addresses.patch Not ok, the "address" (rc5 device) decoding logic will trigger on invalid data as well (0x80 <= data <= 0xc0), which the MSP430 will produce from time to time. In addition there is no logic to read all three bytes and to compare command1 and command2, meaning that the correlation between rc5 device and rc5 command may be wrong (the bytes can arrive in any order). For example, if you receive three bytes from the ir chip: data(device, rc5dev=30) data(command1, rc5cmd=18) data(device, rc5dev=22) Did you just receive command 18 to device 22 or command 18 to device 30? I like that it uses the RC5 toggle bit though, and that it only listens for device 0x1f per default (I had no idea what device code the remotes usually used so I had the reverse logic in my patch). ir_07_cx88xx_name_truncation_and_use_RC5_addresses_for_Hauppauge.patch ir_08_cx88-input_fix_repeat.patch ir_09_cx88-input_prevent_input_layer_repeat_handler.patch No comments, unfamiliar hardware... ir_10_ir-common_compressed_keymaps.patch ir_11_ir-common_optimise_keymap_sizes.patch Honestly, this smells of over-engineering. Compressed, compile-time generated keymaps using a perl-to-c script? I'd rather expect that all keymaps would be removed from the kernel (long term of course) and moved to an external program which loads the proper keymap. This would mean that only the used keymap would take up space and it would be trivial to add new keymaps without hacking kernel code. ... So how would you like to proceed with this? It would be nice to cooperate in order to have the added functionality commited to the dvb repo. Perhaps it would be a good idea to try to get patches 1 - 5 merged first and I can try to update the RC5 command decoding of your sixth patch? That way the first set of changes will also have some time to get some testing before moving along with more changes... -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Allow budget-ci to only listen to certain IR devices
The attached patch changes the IR function in budget-ci so that it reads
all IR sequences from the MSP430 chip. This allows the code to ignore
invalid RC5 codes and also allows it to decide which RC5 device code was
used to send the command (which would fix the problem of using multiple
RC5 remotes [0]).
Per default the driver still listens to commands from all devices, but
using the ir_device parameter, it is possible to limit it to a single
device (which is a good thing if there are other RC5 devices nearby).
Compiled and tested with a programmable remote using a number of
different RC5 device codes.
This patch needs to be applied on top of the dynamic keymap patch posted
earlier[1].
Patch included this time :)
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
[0] http://www.linuxtv.org/mailinglists/linux-dvb/2004/03-2004/msg00721.html
[1] http://www.linuxtv.org/pipermail/linux-dvb/2006-September/013100.html
--
David Härdeman
diff -ur linux-old/drivers/media/dvb/ttpci/budget-ci.c
linux/drivers/media/dvb/ttpci/budget-ci.c
--- linux-old/drivers/media/dvb/ttpci/budget-ci.c 2006-09-26
17:12:41.0 +0200
+++ linux/drivers/media/dvb/ttpci/budget-ci.c 2006-09-27 23:11:25.0
+0200
@@ -65,6 +65,17 @@
#define SLOTSTATUS_READY 8
#define SLOTSTATUS_OCCUPIED
(SLOTSTATUS_PRESENT|SLOTSTATUS_RESET|SLOTSTATUS_READY)
+#define IR_RECV_NONE 0
+#define IR_RECV_DEVICE 1
+#define IR_RECV_CMD1 2
+#define IR_RECV_CMD2 4
+#define IR_RECV_ALL(IR_RECV_DEVICE|IR_RECV_CMD1|IR_RECV_CMD2)
+
+static int ir_device = -1;
+module_param(ir_device, int, 0644);
+MODULE_PARM_DESC(ir_device,
+"Listen to IR commands from given device (0 - 31, default:
all).");
+
struct budget_ci {
struct budget budget;
struct input_dev *input_dev;
@@ -150,36 +161,87 @@
{
struct budget_ci *budget_ci = (struct budget_ci *) data;
struct input_dev *dev = budget_ci->input_dev;
- unsigned int code =
+ static unsigned int code1;
+ static unsigned int code2;
+ static unsigned int device;
+ static int status = IR_RECV_NONE;
+ unsigned int command =
ttpci_budget_debiread(&budget_ci->budget, DEBINOSWAP,
DEBIADDR_IR, 2, 1, 0) >> 8;
- if (code & 0x40) {
- code &= 0x3f;
+ /*
+* Theory of operation
+* ===
+* (from http://home.tiscali.nl/m.majoor/DVBSHardware.pdf)
+*
+* The msp430 generates three different sequences, each one byte:
+* 0x00 <= data < 0x40 = device and toggle information
+* 0x40 <= data < 0x80 = command 1
+* 0x80 <= data < 0xc0 = invalid
+* 0xc0 <= data < 0xff = command 2
+*
+* The device and toggle information byte has the following bit
structure:
+* 00TD, T is the RC5 toggle bit, D are the device code bits (0 -
31)
+*
+* The command bytes have the following bit structure:
+* X1CC, X signifies command 1 or 2, C are the command code bits (0
- 63)
+*
+* The order of the sequences can vary, but a command is only
sucessfully
+* received once all three have appeared at least once, and when the
command 1
+* and command 2 commands match.
+*/
+
+ if (command < 0x40) {
+ /* Device and toggle information */
+ device = command & 0x1f;
+ status |= IR_RECV_DEVICE;
+ dprintk(2, "budget_ci: IR data (device code) - %02x\n", device);
+ } else if (command < 0x80) {
+ /* Command 1 */
+ code1 = command - 0x40;
+ dprintk(2, "budget_ci: IR data (command 1) - %02x\n", code1);
+ status |= IR_RECV_CMD1;
+ } else if (command >= 0xc0 && command <= 0xff) {
+ /* Command 2 */
+ code2 = command - 0xc0;
+ dprintk(2, "budget_ci: IR data (command 2) - %02x\n", code2);
+ status |= IR_RECV_CMD2;
+ } else {
+ /* Invalid */
+ printk("budget_ci: invalid IR data - %02x\n", command);
+ }
- if (timer_pending(&dev->timer)) {
- if (code == dev->repeat_key) {
- ++dev->rep[0];
- return;
- }
- del_timer(&dev->timer);
- input_report_key(dev, INPUT_KEYCODE(dev,
dev->repeat_key), 0);
- }
+ if (status != IR_RECV_ALL || code1 != code2)
+ return;
- if (!INPUT_KEYCODE(dev, code)) {
- printk("DVB (%s): no key for %02x!\n", __FUNCTION__,
code);
+ dprintk(2, "budg
[linux-dvb] [PATCH] Allow budget-ci to only listen to certain IR devices
The attached patch changes the IR function in budget-ci so that it reads all IR sequences from the MSP430 chip. This allows the code to ignore invalid RC5 codes and also allows it to decide which RC5 device code was used to send the command (which would fix the problem of using multiple RC5 remotes [0]). Per default the driver still listens to commands from all devices, but using the ir_device parameter, it is possible to limit it to a single device (which is a good thing if there are other RC5 devices nearby). Compiled and tested with a programmable remote using a number of different RC5 device codes. This patch needs to be applied on top of the dynamic keymap patch posted earlier[1]. Signed-off-by: David Härdeman <[EMAIL PROTECTED]> [0] http://www.linuxtv.org/mailinglists/linux-dvb/2004/03-2004/msg00721.html [1] http://www.linuxtv.org/pipermail/linux-dvb/2006-September/013100.html -- David Härdeman ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Dynamic keymap for budget-ci
The attached patch changes budget-ci so that the keymap can be changed
using the regular input-kbd tool (like it can for other remotes using
ir-kbd-*).
Compiled and tested with a programmable remote.
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
--- linux-2.6.18.orig/drivers/media/dvb/ttpci/budget-ci.c 2006-09-22
18:04:22.0 +0200
+++ linux-2.6.18/drivers/media/dvb/ttpci/budget-ci.c2006-09-23
00:23:16.0 +0200
@@ -136,14 +136,14 @@
struct input_dev *dev = (struct input_dev *) data;
if (dev->rep[0] == 0 || dev->rep[0] == ~0) {
- input_event(dev, EV_KEY, key_map[dev->repeat_key], !!0);
+ input_report_key(dev, INPUT_KEYCODE(dev, dev->repeat_key), 0);
return;
}
dev->rep[0] = 0;
dev->timer.expires = jiffies + HZ * 350 / 1000;
add_timer(&dev->timer);
- input_event(dev, EV_KEY, key_map[dev->repeat_key], 2); /* REPEAT */
+ input_report_key(dev, INPUT_KEYCODE(dev, dev->repeat_key), 2); /*
REPEAT */
}
static void msp430_ir_interrupt(unsigned long data)
@@ -162,10 +162,10 @@
return;
}
del_timer(&dev->timer);
- input_event(dev, EV_KEY, key_map[dev->repeat_key], !!0);
+ input_report_key(dev, INPUT_KEYCODE(dev,
dev->repeat_key), 0);
}
- if (!key_map[code]) {
+ if (!INPUT_KEYCODE(dev, code)) {
printk("DVB (%s): no key for %02x!\n", __FUNCTION__,
code);
return;
}
@@ -177,7 +177,7 @@
/* 350 milliseconds */
dev->timer.expires = jiffies + HZ * 350 / 1000;
/* MAKE */
- input_event(dev, EV_KEY, key_map[code], !0);
+ input_report_key(dev, INPUT_KEYCODE(dev, dev->repeat_key), !0);
add_timer(&dev->timer);
}
}
@@ -187,14 +187,24 @@
struct saa7146_dev *saa = budget_ci->budget.dev;
struct input_dev *input_dev;
int i;
+ u16 *kmap;
+ kmap = kmalloc(sizeof(key_map), GFP_KERNEL);
+ if (!kmap)
+ return -ENOMEM;
budget_ci->input_dev = input_dev = input_allocate_device();
- if (!input_dev)
+ if (!input_dev) {
+ kfree(kmap);
return -ENOMEM;
+ }
sprintf(budget_ci->ir_dev_name, "Budget-CI dvb ir receiver %s",
saa->name);
+ memcpy(kmap, key_map, sizeof(key_map));
input_dev->name = budget_ci->ir_dev_name;
+ input_dev->keycode = kmap;
+ input_dev->keycodesize = sizeof(u16);
+ input_dev->keycodemax = ARRAY_SIZE(key_map);
set_bit(EV_KEY, input_dev->evbit);
for (i = 0; i < ARRAY_SIZE(key_map); i++)
@@ -222,6 +232,7 @@
if (del_timer(&dev->timer))
input_event(dev, EV_KEY, key_map[dev->repeat_key], !!0);
+ kfree(dev->keycode);
input_unregister_device(dev);
}
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
