date:20090523

On Sat, May 23, 2009 at 9:51 AM, David Lister foc...@gmail.com wrote:
 Manu Abraham wrote:
 On Sat, May 23, 2009 at 1:30 AM, David Lister foc...@gmail.com wrote:

 Actually, there are many DVB-S2 cards supporting 45 MS/s, even TeVii S460
 can do 2-45 MS/s. I spoke with a fellow TeVii owner, who confirmed the card
 is working with a 45 MS/s transponder on Express AM2 without *any* issues.
 All this aside, there aren't any transponders with higher rates than this
 and there won't be for many years. Who knows how stable would TT even be
 with such rates? For now, it's irrelevant anyway. I have no problem
 upgrading to a new card in 3-4 years, providing there will be a stable,
 fully supported card for Linux with as many satisfied owners as e.g. Nova S2
 HD has.


 You are talking about a 45 MSPS DVB-S stream on a DVB-S2 demodulator,
 while i was talking about a 45 MSPS DVB-S2 stream on a DVB-S2 demodulator.

 Big difference !


 This point is moot in the first place, mate. Especially in USA (original
 poster), where it'll take twice the time to reach those rates on DVB-S2.
 All current 45 MS/s transponders are QPSK, at least as far as I can
 tell. Even if that technology preview 8PSK transponder of yours
 existed (somewhere above Asia), it's hardly a reason to buy
 Linux-unstable cards in EU or USA.


Have you tried the card, to state that it is unstable ? I would like
to know the basis
for your comments to state that it is unstable.


 Especially considering OP's quest for
 super-stable HW. HD is pretty much beginning and none of it goes over 30
 MS/p. Why hurry, I ask? In 2-3 years time, when your driver is finished
 and stable, we'll all happily switch to generation 2 HW (your term),
 if need be. Don't get me wrong, I have nothing against TT,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about driver for Mantis

On Sat, May 23, 2009 at 10:10 AM, Jarosław Huba jarhu...@poczta.onet.pl wrote:
 Hi.
 Is driver for Mantis chipset are currently developed somewhere?
 I'm owner of Azurewave AD SP400 CI (VP-1041) and I'm waiting for support for
 this card for quite long time. Even partly working driver in mainline kernel
 would be great (without remote, CI, S2 support, with some tuning bugs).
 This question is mainly for Manu Abraham who developed this driver some time
 ago.

The latest development snapshot for the mantis based devices can be found
here: http://jusst.de/hg/mantis-v4l

Currently CI is unsupported, though very preliminary code support for
it exists in it.
S2 works, pretty much. Or do you have other results ?

Regards,
Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)

2009-05-23 Thread Martin Dauskardt

Hi Andy,

 Martin,
 
 I don't see tuner type 81 in the list in tuners.h.  I do see:
 
 
 #define TUNER_PHILIPS_FQ1216ME          24      /* you must actively select 
B/G/D/K, I, L, L` */
 #define TUNER_PHILIPS_FQ1216AME_MK4     56      /* Hauppauge PVR-150 PAL */
 
 #define TUNER_PHILIPS_FM1216ME_MK3      38
 
 #define TUNER_PHILIPS_FMD1216ME_MK3     63
 #define TUNER_PHILIPS_FMD1216MEX_MK3    78
 #define TUNER_PHILIPS_FM1216MK5         79

ah, sorry. I looked into hauppauge_tuner[] from tveeprom.c and also misread 
the internal number 80 as 81:

/* 80-89 */
{ TUNER_PHILIPS_FM1216ME_MK3,   Philips FQ1216LME MK3},

 
 Could the user try one of those, starting with the FQ1216 tuner numbers
 (24 and 56), to see if one of them works?  For the FQ1261LME MK3,
 tveeprom has the FM1216ME_MK3 tuner number (38).

I hope to get in contact with him this weekend. There is another problems with 
the application which must be solved before, but I am sure we will found out 
the right tuner type at the end.

Greets,
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

2009-05-23 Thread Pekka Enberg

On Sat, May 23, 2009 at 12:32 AM, David da...@unsolicited.net wrote:
 I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
 finally had time to do some digging, and the regression is caused by:

    b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci-hcd unlink speedups

 ..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5
 makes the card work happily again.

[ Note: David meant 2.6.30-rc5 here. ]

Thanks for doing the bisect!

On Sat, May 23, 2009 at 12:32 AM, David da...@unsolicited.net wrote:
 I don't know enough about USB protocols to speculate on whether there
 may be a better fix, but hopefully someone cleverer than me can get to
 the bottom of the problem?

Lets start with cc'ing the right people. :-)

Pekka
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Most stable DVB-S2 PCI Card?

On Sat, May 23, 2009 at 2:03 PM, David Lister foc...@gmail.com wrote:
Manu Abraham wrote:
On Sat, May 23, 2009 at 9:51 AM, David Lister foc...@gmail.com wrote:

This point is moot in the first place, mate. Especially in USA (original
poster), where it'll take twice the time to reach those rates on DVB-S2.
All current 45 MS/s transponders are QPSK, at least as far as I can
tell. Even if that technology preview 8PSK transponder of yours
existed (somewhere above Asia), it's hardly a reason to buy
Linux-unstable cards in EU or USA.

Have you tried the card, to state that it is unstable ? I would like
to know the basis
for your comments to state that it is unstable.

I was not talking specifically about TT-1600, but with your drivers
being relatively young, not in wide use, and you being the only
developer (right?), it's common sense to assume that they are not as
stable as e.g. cx88.

LOL, As stable as CX88, you must be joking. As far as the number of
developers on the card, if you are as capable of reading what you claim,
you can see that from the changelogs, in the main tree itself.

You mean the SAA7146 driver is young ? Hmm.. pretty ignorant comments,
you seem to make. The 7146 is one of the oldest driver that exists.
Exception is bttv which is still older.

Also considering the fact that none of these
drivers even report signal stats properly. Then, of course, there's my
recent experience with your SkyStar HD2 driver. :)

Which card are you talking about ? Your experience with the Skystar HD
driver == USER Error, that's what some people would think.

The mantis driver is a driver which is very much in development. You
should've read it on the ML's itself. It's really sad that you are pretty much
ignorant. A driver which is in development, you expect all sorts of issues.
That's why it is in an external tree.

Now, you managed to get hold of the wrong tree, burned your demodulator,
inspite of me warning users on the ML's many times. So you are still
ignorant on that. You decided to do, what it pleased you. Not my fault.

I guess, you don't understand the term Development, Stable etc either.

The TT S2-1600 support is much different, support for it exist in the mainline
tree, which is verified. The SAA7146 bridge which the S2-1600 is based on,
is the most mature PCI multimedia bridge that exists under Linux.

Also you seem completely ignorant about how Linux development goes on.

You have to
understand that me, in this case just a common user, do not wish to
invest into a product with an unfinished driver. If it was for me, I
wouldn't really care, but with the whole family using the HTPC...

I didn't want to write a long mail, but here goes:

The TechnoTrend company, as of Februay 2009, doesn't exists any more.
*It is bankrupt*. First, its owner Novabase sold as many of its shares
as it could in 2007, in hope that the proceeds would allow TechnoTrend
to get back on track. No such luck. A few months back this year, the
company was finally dumped and sold as a whole to some German telco
company in the Kathrein Group for liquidation, because of the tremendous
drop in it's market value and forthcoming bankruptcy. This might also be
of some interest to prospective buyers of it's former products. :) I
don't want to search for all the press releases, but you can verify this
claim here:
http://www.euronext.com/fic/000/044/480/444806.pdf

I don't work for Technotrend, neither have i till now. My opinions are my own.
I don't care about your completely non-technical or trolling posts. Whether
Technotrend is having a new ownership/management is as well nothing of
concern to me.

There seems to be people buying thedead product that you claim and hence the
support for it is in.

Nevertheless, I tried to get the data-sheet for this dead product from
their closed down discontinued sites. Google cache is a great thing, I
managed to find TechnoTrend's S2-1600 data-sheet PDF:
http://www.pt.technotrend.com/Dokumente/87/Manuals_PC/specs_eng/TechSpec_S2-1600_engl.pdf

As much as I'd like to believe your S2-1600 supports 63 MS/s, I cannot
ignore the fact that the manufacturer disagrees with you:
DVB-S: 2 - 45 MS/s
DVB-S2: 10 - 30 MS/s

It's not a card manufacturer that do make the chip specifications.
You can look at the STV0903 specification, or the announcement that i
made earlier on the list about the same.

From the Cut 2.0 chips onwards, The STV0900/903 demodulators do support
45 MSPS officially and unofficially 60 MSPS with 8PSK modulation. Anything
predating Cut 2.0 you don't find on any PC related products.

http://linuxtv.org/hg/v4l-dvb/rev/4882c97b0540

Pretty standard specs, if you ask me. Obviously, you must have proven
the *manufacturer* wrong by verifying your claim in practice. I just
wonder how you did it, when no existing DVB-S2 transponder uses rates
over 30 MS/s. Wasn't it perhaps just some dry testing without any
signal, like gradually raising the HW

Re: Question about driver for Mantis

2009/5/23 Jarosław Huba jarhu...@poczta.onet.pl:
 The latest development snapshot for the mantis based devices can be found
 here: http://jusst.de/hg/mantis-v4l

 Currently CI is unsupported, though very preliminary code support for
 it exists in it.
 S2 works, pretty much. Or do you have other results ?

 Regards,
 Manu

 I will test it soon. Do I need to compile my own pathed kernel? Or Is there
 some info on wiki about how to do that in easier way?
 I'm using Kubuntu Karmic with kernel 2.6.30.


Just clone the tree on to your machine
hg clone http://jusst.de/hg/mantis-v4l

Clean stal remnants if any.
make distclean

Build the tree
make

Load the modules

one by one,
or have a script of your own to load it,
or you can do a make install


In case you are sending me debug output, please do load the
mantis.ko and stb0899.ko modules with the verbose=5
module parameter, so that the debug messages are verbosed out.

Otherwise you can forget about the module parameters.

Regards,
Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] High resolution timer for cx88 remotes

2009-05-23 Thread AH


Hi

Some remotes requires short polling interval which in modern kernels is 
below resolution of standard scheduler (schedule_delayed_work), this 
causes problem of missed keystrokes. One of the solutions is to raise 
kernel timer frequency, my proposition is to use high resolution timers 
which are present in kernel since 2.6.16 (at least API AFAIK).
I have encountered this problem on my Winfast 2000XP Expert, but after 
checking cx88-input.c it seems that following cards can be affected also:

WINFAST2000XP_EXPERT
WINFAST_DTV1000
WINFAST_TV2000_XP_GLOBAL
PROLINK_PLAYTVPVR
PIXELVIEW_PLAYTV_ULTRA_PRO
PROLINK_PV_8000GT
PROLINK_PV_GLOBAL_XTREME
KWORLD_LTV883
MSI_TVANYWHERE_MASTER

Patched driver seems to work on my system, with kernel 2.6.28.
I have removed kernel checks for versions below 2.6.20 - they were 
because of API changes in scheduler.


I have not tested it on older kernels.

Regards
AH

diff -r 315bc4b65b4f linux/drivers/media/video/cx88/cx88-input.c
--- a/linux/drivers/media/video/cx88/cx88-input.c   Sun May 17 
12:28:55 2009 +
+++ b/linux/drivers/media/video/cx88/cx88-input.c   Sat May 23 
14:04:17 2009 +0200

@@ -23,10 +23,10 @@
 */

#include linux/init.h
-#include linux/delay.h
#include linux/input.h
#include linux/pci.h
#include linux/module.h
+#include linux/hrtimer.h

#include compat.h
#include cx88.h
@@ -49,7 +49,7 @@

   /* poll external decoder */
   int polling;
-   struct delayed_work work;
+   struct hrtimer timer;
   u32 gpio_addr;
   u32 last_gpio;
   u32 mask_keycode;
@@ -144,31 +144,25 @@
   }
}

-#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,20)
-static void cx88_ir_work(void *data)
-#else
-static void cx88_ir_work(struct work_struct *work)
-#endif
+enum hrtimer_restart cx88_ir_work(struct hrtimer *timer)
{
-#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,20)
-   struct cx88_IR *ir = data;
-#else
-   struct cx88_IR *ir = container_of(work, struct cx88_IR, work.work);
-#endif
+   unsigned long missed;
+   struct cx88_IR *ir = container_of(timer, struct cx88_IR, timer);

   cx88_ir_handle_key(ir);
-   schedule_delayed_work(ir-work, msecs_to_jiffies(ir-polling));
+   missed = hrtimer_forward_now(ir-timer, ktime_set(0, 
ir-polling * 100));

+   if (missed  1)
+   ir_dprintk(Missed ticks %ld\n, missed - 1);
+
+   return HRTIMER_RESTART;
}

void cx88_ir_start(struct cx88_core *core, struct cx88_IR *ir)
{
   if (ir-polling) {
-#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,20)
-   INIT_DELAYED_WORK(ir-work, cx88_ir_work, ir);
-#else
-   INIT_DELAYED_WORK(ir-work, cx88_ir_work);
-#endif
-   schedule_delayed_work(ir-work, 0);
+   hrtimer_init(ir-timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+   ir-timer.function = cx88_ir_work;
+   hrtimer_start(ir-timer, ktime_set(0, ir-polling * 
100), HRTIMER_MODE_REL);

   }
   if (ir-sampling) {
   core-pci_irqmask |= PCI_INT_IR_SMPINT;
@@ -185,7 +179,7 @@
   }

   if (ir-polling)
-   cancel_delayed_work_sync(ir-work);
+   hrtimer_cancel(ir-timer);
}

/* 
-- */


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about driver for Mantis

2009-05-23 Thread Gernot Pansy

hy,

On Saturday 23 May 2009 08:41:48 Manu Abraham wrote:
 On Sat, May 23, 2009 at 10:10 AM, Jarosław Huba jarhu...@poczta.onet.pl 
wrote:
  Hi.
  Is driver for Mantis chipset are currently developed somewhere?
  I'm owner of Azurewave AD SP400 CI (VP-1041) and I'm waiting for support
  for this card for quite long time. Even partly working driver in mainline
  kernel would be great (without remote, CI, S2 support, with some tuning
  bugs). This question is mainly for Manu Abraham who developed this driver
  some time ago.

 The latest development snapshot for the mantis based devices can be found
 here: http://jusst.de/hg/mantis-v4l

 Currently CI is unsupported, though very preliminary code support for
 it exists in it.
 S2 works, pretty much. Or do you have other results ?

will CI be supported and are you willing to finish development and merge it to 
mainline anytime?

i think i was one of the first SP400 owner but i had to sold my card for a Nova 
HD2 because the driver was not reliable (some i2c errors, slow tunning, 
sometimes tunning failed). And now i need a dvb-s2 card with ci working. so 
i'm searching again for a new card. their seems to be only the tt-3200 out, 
which seems to work - no newer card. 

regards,
gernot


 Regards,
 Manu
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] SDMC DM1105N not being detected

2009-05-23 Thread Igor M. Liplianin

On 20 May 2009 16:44:22 Simon Kenyon wrote:
 mp3geek wrote:
  Not even being detected in Linux 2.6.29.1, I have the modules dm1105
  loaded, but since its not even being detected by linux..
 
  lspci -vv shows this (I'm assuming this is the card..), dmesg shows
  nothing dvb being loaded
 
  00:0b.0 Ethernet controller: Device 195d:1105 (rev 10)
  Subsystem: Device 195d:1105
  Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
  ParErr- Stepping- SERR- FastB2B- DisINTx-
  Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
  TAbort- MAbort- SERR- PERR- INTx-
  Latency: 30 (4000ns min, 8000ns max), Cache Line Size: 32 bytes
  Interrupt: pin A routed to IRQ 5
  Region 0: I/O ports at 9400 [size=256]
 
 
  The chip says the following, SDMC DM1105N, EasyTV-DVBS V1.0B
  (2008-04-26), 0735 E280034

 because i saw that there was a driver written by igor, i took a chance
 and bought a DM04 DVB-S card on ebay. it only cost ─20 (including
 shipping from HK to Ireland) so i reckoned nothing ventured, nothing
 gained
 on a windows box it runs rather nicely. granted that the software
 provided does not provide a BDA driver, so you are pretty much limited
 to the stuff that comes with the card.
 but a big me too on linux (which is what i bought it for)
 i similarly get an ethernet controller and nothing in the kernel log
 when i load the dm1105 module.

 what do i need to do to debug the situation and/or update the driver?

 regards
 --
 simon

It seems, one can find GPIO values for LNB power control.
Do not forget about Vendor/Device ID's. 

I wrote code to support card with subsystem/device 195d/1105, but no one 
reported success, so I 
decided not to include it in commit :(

It was more then one year ago

http://liplianin.at.tut.by/dvblipl.tar.bz2

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Most stable DVB-S2 PCI Card?

Manu Abraham wrote:
 LOL, As stable as CX88, you must be joking. As far as the number of
 developers on the card, if you are as capable of reading what you claim,
 you can see that from the changelogs, in the main tree itself.

 You mean the SAA7146 driver is young ? Hmm.. pretty ignorant comments,
 you seem to make. The 7146 is one of the oldest driver that exists.
 Exception is bttv which is still older.
   
Indeed LOL, as you say. I do not wish to torment you any longer. :) It
is always sad to see people switch to personal insults, when they run
out of arguments. This wasn't my intention and therefore I'm withdrawing
from this thread with my apologies for making you angry.

Some last replies: I wasn't talking about the number of developers on
cx88, was I? I was talking about your driver and you being its sole
developer; cx88 has the advantage of being proven by time as stable (in
contrast to your *new* TT-1600 support, where things like number of
developers has objective informational value). You also seem to confuse
chips (i.e. the building blocks) and complete products. Is it not true
that your first attempt at S2-1600 support was submited on April 23rd,
2009? You see for me, this is *new*.

 Also considering the fact that none of these
 drivers even report signal stats properly. Then, of course, there's my
 recent experience with your SkyStar HD2 driver. :)
 
 Which card are you talking about ? Your experience with the Skystar HD
 driver == USER Error, that's what some people would think.

   
Well, that is what *you* think, because you weren't able to explain why
it didn't work properly. There were some driver difficulties, but what
did you expect when there are at least three different branches of the
driver, all devel:

http://jusst.de/hg/mantis
http://mercurial.intuxication.org//hg//s2-liplianin
http://jusst.de/hg/mantis-v4l

I used the last driver a few hours after it was uploaded (and suggested
on the list), so don't make this a USER issue.

 The mantis driver is a driver which is very much in development. You
 should've read it on the ML's itself. It's really sad that you are pretty much
 ignorant. A driver which is in development, you expect all sorts of issues.
 That's why it is in an external tree.
   
Oh, but I've read the list before buying the card, just like I've done
for over 10 years for all HW for my Linux setups. Plus the reference
information on the linuxtv.org says the driver is in development for
over 3 years. When you see people discussing just lame  minor details
on the lists and when there's a 3yr old driver, you usually expect no
problems (not many anyway). But this is not my issue - please understand
that I'm not complaining at all, this is just a reply to your previous
statement. It is OT in this argument.

 Now, you managed to get hold of the wrong tree, burned your demodulator,
 inspite of me warning users on the ML's many times. So you are still
 ignorant on that. You decided to do, what it pleased you. Not my fault.
   
As I wrote above, s2-liplianin was the latest tree available for general
public at the time. My only other option was multiproto. I used
mantis-v4l tree even before it was completely uploaded.

As soon as the new S2API mantis tree was mentioned on the list, I used
it. But most importantly, your only explanation that it still doesn't
work, because I burned my demodulator using the current s2-liplianin
tree is *absolutely* ridiculous. You might work it out with Liplianin
himself, but if you had read my followup, you would know that I
exchanged the card for new samples, had those samples *verified* by
TechniSat (your second and last explanation was that my HW is fake, LOL)
and I used *only* your latest driver. Of course it demonstrated the same
exact issues as previous burned (haha) cards.


 I guess, you don't understand the term Development, Stable etc either.
   
I did not expect everything rosy, I have my share of Linux HW
experiences. I've also written a complete Linux driver for a device I
had, which wasn't supported - that driver is now part of the kernel. So
believe me, not only I know how open source development works, I even
know how kernel driver development works. What I did not expect was
almost total ignorance of my issues by the driver author himself. One
would expect at least some cooperation, I know how hard it is to find
testers of one's code. You offered two explanations why your devel
driver didn't work: the HW is broken or fake. Nice!

In the end, I didn't return the cards because of the driver. I could
live without PWR, SNR monitoring and unstable locks. I gave up, because
even when everything worked, there were two major HW problems (caused by
driver):
1) Card's HW emitted high pitched noise (like old TV's, but louder) as
soon as I got DVB-S2 lock (mantis-v4l)
2) All DVB-S/S2 channels were corrupted, the picture looked as if there
was a weak signal (STB reports 95%!). Intolerable.

Yet, cx88 card on the exact same setup works

Re: [linux-dvb] Most stable DVB-S2 PCI Card?

 As soon as the new S2API mantis tree was mentioned on the list, I used it.
 But most importantly, your only explanation that it still doesn't work,
 because I burned my demodulator using the current s2-liplianin tree is
 *absolutely* ridiculous. You might work it out with Liplianin himself,


No, you happened to be a complete idiot inspite of doing sane things,
being repeatedly warned with posts on the Mailing List. If you can't read,
you suffer from it. s2-liplianin was created with some cause for promoting
the hardware what you were trying to promote. So definitely it is that way.
I can't help that you ran arbitrary code on your computer  and got screwed.


 I did not expect everything rosy, I have my share of Linux HW experiences.
 I've also written a complete Linux driver for a device I had, which wasn't
 supported - that driver is now part of the kernel. So believe me, not only I
 know how open source development works, I even know how kernel driver
 development works.


half baked one's are the usual problematic one's. There used to be one crying
loud over documentation patches.



 This is true, but do you know how the chips are integrated in TT-1600. Final
 consumer product using certain chipsets usually does miss some features or
 parameter ranges of the integrated chips (especially SoC chips). Have you
 ever seen a PC motherboard? Well, now that you know how I meant what I said,
 it is perhaps time to acknowledge that the *card* manufacturer usually knows
 what their product is capable of. You know, they being the people who
 actually design all the circuitry on the PCB...


First of all i had completely no clue on it. That's why i was able to
write a driver for it.
(with sarcasm)
Mate you have no clue. The S2-1600 is based on a reference design and hence.
You have a lot to understand. I don't give it a damn which way to take
it to heart.


Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about driver for Mantis

2009/5/23 Gernot Pansy ger...@pansy.at:
 hy,

 On Saturday 23 May 2009 08:41:48 Manu Abraham wrote:
 On Sat, May 23, 2009 at 10:10 AM, Jarosław Huba jarhu...@poczta.onet.pl
 wrote:
  Hi.
  Is driver for Mantis chipset are currently developed somewhere?
  I'm owner of Azurewave AD SP400 CI (VP-1041) and I'm waiting for support
  for this card for quite long time. Even partly working driver in mainline
  kernel would be great (without remote, CI, S2 support, with some tuning
  bugs). This question is mainly for Manu Abraham who developed this driver
  some time ago.

 The latest development snapshot for the mantis based devices can be found
 here: http://jusst.de/hg/mantis-v4l

 Currently CI is unsupported, though very preliminary code support for
 it exists in it.
 S2 works, pretty much. Or do you have other results ?

 will CI be supported and are you willing to finish development and merge it to
 mainline anytime?


The CI code is out there in it itself commented out, but is a bit
unstable. I haven't
spent too much time on it these last 2 months, due to lack of time


 i think i was one of the first SP400 owner but i had to sold my card for a 
 Nova
 HD2 because the driver was not reliable (some i2c errors, slow tunning,
 sometimes tunning failed). And now i need a dvb-s2 card with ci working. so
 i'm searching again for a new card. their seems to be only the tt-3200 out,
 which seems to work - no newer card.


The issue with the I2C errors have been fixed in the
jusst.de/hg/mantis-v4l tree.
It had been a bit hard to fix, but i am almost certain, that issue is
gone for good.

There were quite a lot of fixes to the stb0899 module, so maybe some of the
issues what you looked at might've been fixed.

Regards,
Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes

2009-05-23 Thread BOUWSMA Barry

Moin Devin, thanks for the reply.

On Fri, 22 May 2009, Devin Heitmueller wrote:

[cut my drivel]
 The dvb core does have infrastructure to support hardware pid
 filtering.

If you don't mind, and this is a serious question, could you
give me some keywords to look for?  I've come up with some
obvious winners in dvb-usb with uppercase FILTER, but lowercase
filter didn't give me any serious Aha! moments for other
devices, in an attempt to determine device capabilities by
simple code reading.  Thanks!  (And I'll gladly eat my shoes
when it turns out to be something stupendously simple, as I'm
no code-reader)


   I don't know too much about the DVB standards, but I know
 that ATSC is 19.39MB/s and QAM as deployed in US cable systems is
 about twice that.  Neither would fit in a 12Mbps stream.

Bleedin' 'ell, I knew things were bigger in Texas, but I
didn't know they wuz that big!  ;-)  Just kidding, I know
what you meant...

Just for background, the overall bandwidth of DVB-T will be
determined by choice of frequency at one transmitter site or
whether shared by several and how far apart, as well as other
factors that are basically able to be simplified as a tradeoff
of reliability over distance against bandwidth.  There's a wide
variance here, but in even the most widely-reaching Single-
Frequency-Networks that are meant to be received at large
distances under difficult conditions, where available overall
bandwidth is less than that of a single transmitter serving
a local area, said overall bandwidth is generally going to
exceed that which I've achieved from USB1.1.  A certain DVB-H 
network with 1/2 FEC and 1/4 guard interval drops below
10 000kbit/sec but isn't likely to represent common usage
for broadcast TV services.

On the other hand, the individual services within each
multiplex will generally be well within the USB1.1 available
bandwidth, provided hardware PID filtering can be applied.
Bitrates for television services can be from some 2Mbit/sec
up to over 5Mbit/sec at times, depending on whether that
service has been configured to get the lion's share of the
bandwidth at the expense of the other services with rates
dynamically varying based on picture content thanks to
statistical multiplexing.

In any case, while I've been able to watch average-per-second
bitrates of different PIDs on different multiplexes, I've
just realized that I haven't actually used any DVB-T
receivers for any length of time on a USB1.1 port to see
if instantaneous bursts will exceed that bandwidth, as is
the case for quality services delivered via DVB-S and USB1.1.

But I've read that it's the exception rather than the rule
that a particular service will be privileged to get more
than its proportional share of overall bandwidth, to be free
of most artifacts and be watchable, so I'd be willing to posit 
that a full service (video, multiple audio, PMT, teletext, and 
the like) will fit onto USB1.1.

So much for background.  Anyone still bothering to read?


 If I knew of a em2874/em2884 device that also didn't use the drx, I
 would consider it worthwhile to spend the time to do the work for the
 hardware filtering.  Until that happens though, I've got better things
 to spend my time on.

No argument there.  I had a look through Herr Rechberger's
code (simply because it's had a wider variety of included
hardware, not to say anything about the linuxtv code) to get
a feel for how many devices were exclusively DVB-T, or at
least didn't include some baseband video.

It appears that a group of EM2870 devices (may well be the
2874 in reality, I just numbly scan the code) are limited
to DVB-T, including Terratec Cinergy T XS, Pinnacle PCTV DVB-T,
a couple KWorld 35xU DVB-T devices, and a Compro VideoMate.
Apart from that, all remaining devices (apart from DMB and
the like) appear to have the ability to handle analogue
signals, and need USB2.0 to reach full potential.



 filtering in conjunction with USB 2.0.  The fix is really in response
 to users with older PCs trying to capture a full ATSC stream (or
 analog capture), and being *very* confused.  If there is really a
 concern that we should be supporting USB 1.1 ports, even though USB
 2.0 has been around for almost ten years, I guess I can add a modprobe
 option to allow the user to override the check.

I actually have dredged from the dank dingy decaying dumpster 
depths or doom a machine fast enough to decode and display SD 
images, even without XVMC MPEG-2 acceleration, after replacing 
most of the electrolytic condensers/capacitors on the board, yet 
the internal USB ports are again 1.1.  Given all the Blinkenlights
it's probably an ex-gamer machine, but compared with my machine
at some 1/7 the CPU clock, it's not as obsolete as it could be,
though that still doesn't stop me from periodically wanting to
hurl it across the room every so often.

So there are probably still a fair number of boxen out there
with internal USB1.1 ports, that would be my guess.  And while
I've added

[PATCH] em28xx device mode detection based on endpoints

Hi,

for em28xx devices the device node detection can be based on the
encoded endpoint address, for example EP 0x81 (USB IN, Interrupt),
0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts input
EP).
It is not necessary that digital TV devices have a frontend, the
em28xx chip only specifies an MPEG-TS input EP.

Following patch adds a check based on the Endpoints, although it might
be extended that all devices match the possible devicenodes based on
the endpoints, currently the driver registers an analog TV node by
default for all unknown devices which is not necessarily correct, this
patch disables the ATV node if no analog TV endpoint is available.

best regards,
Markus
diff -r 315bc4b65b4f linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c	Sun May 17 12:28:55 2009 +
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c	Sat May 23 16:03:39 2009 +0200
@@ -1596,9 +1596,13 @@
 /* Since em28xx_pre_card_setup() requires a proper dev-model,
  * this won't work for boards with generic PCI IDs
  */
-void em28xx_pre_card_setup(struct em28xx *dev)
+static int em28xx_pre_card_setup(struct em28xx *dev,
+struct usb_interface *intf)
 {
 	int rc;
+	int i;
+	struct usb_host_interface *host_interface = intf-altsetting[0];
+	int select_alt;
 
 	em28xx_set_model(dev);
 
@@ -1647,6 +1651,18 @@
 		}
 	}
 
+	/* this is for protecting wrong devices against the rest of the control
+	   commands
+	   for example:
+	   $ cd /sys/bus/usb/drivers/em28xx
+	   $ echo 1234 1234  new_id
+	*/
+
+
+	if (dev-model == EM2800_BOARD_UNKNOWN 
+		dev-chip_id = CHIP_ID_EM2883)
+		dev-lock_control_commands = 1;
+
 	/* Prepopulate cached GPO register content */
 	rc = em28xx_read_reg(dev, dev-reg_gpo_num);
 	if (rc = 0)
@@ -1658,8 +1674,66 @@
 	em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, dev-board.i2c_speed);
 	msleep(50);
 
+	if (dev-model != EM2800_BOARD_UNKNOWN)
+		/* defaulting to have the same behaviour as we always had */
+		dev-has_atv = 1;
+
 	/* request some modules */
 	switch (dev-model) {
+	case EM2800_BOARD_UNKNOWN:
+		if (dev-chip_id  CHIP_ID_EM2820) {
+			/* defaulting again .. */
+			dev-has_atv = 1;
+			break;
+		}
+
+		em28xx_info(Probing device modes (ignore all upcoming
+			 errors)\n);
+		em28xx_info(Found endpoints: %d\n,
+host_interface-desc.bNumEndpoints);
+		em28xx_info(Found alternate: %d\n, dev-num_alt);
+
+		switch (dev-num_alt) {
+		case 2:
+			select_alt = 1;
+			break;
+		case 8:
+			select_alt = 7;
+			break;
+		default:
+			/* guaranteed no EETI TV device */
+			return -EINVAL;
+		}
+		for (i = 0; i  host_interface-desc.bNumEndpoints; i++) {
+			em28xx_info(Alternate setting %d [%02x]\n,
+select_alt,
+intf-altsetting[select_alt].endpoint[i].
+	desc.bEndpointAddress);
+
+			switch (intf-altsetting[select_alt].endpoint[i].
+desc.bEndpointAddress) {
+			case EM28XX_INTERRUPT_EP:
+/* currently not implemented */
+break;
+			case EM28XX_ANALOG_VIDEO_EP:
+/* registered by default already which
+   is bogus */
+em28xx_info(FOUND ATV EP\n);
+dev-has_atv = 1;
+break;
+			case EM28XX_ANALOG_AUDIO_EP:
+em28xx_info(Found PCMAUDIO EP\n);
+dev-has_alsa_audio = 1;
+break;
+			case EM28XX_DIGITALTV_EP:
+em28xx_info(Found MPEG-TS EP\n);
+dev-has_dvb = 1;
+break;
+			default:
+return -EINVAL;
+			}
+		}
+		break;
 	case EM2861_BOARD_PLEXTOR_PX_TV100U:
 		/* FIXME guess */
 		/* Turn on analog audio output */
@@ -1748,6 +1822,7 @@
 
 	/* Unlock device */
 	em28xx_set_mode(dev, EM28XX_SUSPEND);
+	return 0;
 }
 
 static void em28xx_setup_xc3028(struct em28xx *dev, struct xc2028_ctrl *ctl)
@@ -2191,8 +2266,12 @@
 	dev-em28xx_write_regs_req = em28xx_write_regs_req;
 	dev-em28xx_read_reg_req = em28xx_read_reg_req;
 	dev-board.is_em2800 = em28xx_boards[dev-model].is_em2800;
+	dev-has_dvb = dev-board.has_dvb;
 
-	em28xx_pre_card_setup(dev);
+	retval = em28xx_pre_card_setup(dev, interface);
+
+	if (retval)
+		return retval;
 
 	if (!dev-board.is_em2800) {
 		/* Sets I2C speed to 100 KHz */
@@ -2265,16 +2344,19 @@
 
 	em28xx_add_into_devlist(dev);
 
-	retval = em28xx_register_analog_devices(dev);
-	if (retval  0) {
-		em28xx_release_resources(dev);
-		goto fail_reg_devices;
+	if (dev-has_atv) {
+		retval = em28xx_register_analog_devices(dev);
+		if (retval  0) {
+			em28xx_release_resources(dev);
+			goto fail_reg_devices;
+		}
 	}
 
 	em28xx_init_extension(dev);
 
-	/* Save some power by putting tuner to sleep */
-	v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_standby);
+	if (dev-has_atv)
+		/* Save some power by putting tuner to sleep */
+		v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_standby);
 
 	return 0;
 
diff -r 315bc4b65b4f linux/drivers/media/video/em28xx/em28xx-core.c
--- a/linux/drivers/media/video/em28xx/em28xx-core.c	Sun May 17 12:28:55 2009 +
+++ b/linux/drivers/media/video/em28xx/em28xx-core.c	Sat May 23 16:03:39 2009 +0200
@@ -68,7 +68,12 @@
    char *buf, int len)
 {

Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes

On Sat, May 23, 2009 at 4:00 PM, BOUWSMA Barry
freebeer.bouw...@gmail.com wrote:
 Moin Devin, thanks for the reply.

 On Fri, 22 May 2009, Devin Heitmueller wrote:

 [cut my drivel]
 The dvb core does have infrastructure to support hardware pid
 filtering.

 If you don't mind, and this is a serious question, could you
 give me some keywords to look for?  I've come up with some
 obvious winners in dvb-usb with uppercase FILTER, but lowercase
 filter didn't give me any serious Aha! moments for other
 devices, in an attempt to determine device capabilities by
 simple code reading.  Thanks!  (And I'll gladly eat my shoes
 when it turns out to be something stupendously simple, as I'm
 no code-reader)


   I don't know too much about the DVB standards, but I know
 that ATSC is 19.39MB/s and QAM as deployed in US cable systems is
 about twice that.  Neither would fit in a 12Mbps stream.

 Bleedin' 'ell, I knew things were bigger in Texas, but I
 didn't know they wuz that big!  ;-)  Just kidding, I know
 what you meant...

 Just for background, the overall bandwidth of DVB-T will be
 determined by choice of frequency at one transmitter site or
 whether shared by several and how far apart, as well as other
 factors that are basically able to be simplified as a tradeoff
 of reliability over distance against bandwidth.  There's a wide
 variance here, but in even the most widely-reaching Single-
 Frequency-Networks that are meant to be received at large
 distances under difficult conditions, where available overall
 bandwidth is less than that of a single transmitter serving
 a local area, said overall bandwidth is generally going to
 exceed that which I've achieved from USB1.1.  A certain DVB-H
 network with 1/2 FEC and 1/4 guard interval drops below
 10 000kbit/sec but isn't likely to represent common usage
 for broadcast TV services.

 On the other hand, the individual services within each
 multiplex will generally be well within the USB1.1 available
 bandwidth, provided hardware PID filtering can be applied.
 Bitrates for television services can be from some 2Mbit/sec
 up to over 5Mbit/sec at times, depending on whether that
 service has been configured to get the lion's share of the
 bandwidth at the expense of the other services with rates
 dynamically varying based on picture content thanks to
 statistical multiplexing.

 In any case, while I've been able to watch average-per-second
 bitrates of different PIDs on different multiplexes, I've
 just realized that I haven't actually used any DVB-T
 receivers for any length of time on a USB1.1 port to see
 if instantaneous bursts will exceed that bandwidth, as is
 the case for quality services delivered via DVB-S and USB1.1.

 But I've read that it's the exception rather than the rule
 that a particular service will be privileged to get more
 than its proportional share of overall bandwidth, to be free
 of most artifacts and be watchable, so I'd be willing to posit
 that a full service (video, multiple audio, PMT, teletext, and
 the like) will fit onto USB1.1.

 So much for background.  Anyone still bothering to read?


 If I knew of a em2874/em2884 device that also didn't use the drx, I
 would consider it worthwhile to spend the time to do the work for the
 hardware filtering.  Until that happens though, I've got better things
 to spend my time on.

 No argument there.  I had a look through Herr Rechberger's
 code (simply because it's had a wider variety of included
 hardware, not to say anything about the linuxtv code) to get
 a feel for how many devices were exclusively DVB-T, or at
 least didn't include some baseband video.

 It appears that a group of EM2870 devices (may well be the
 2874 in reality, I just numbly scan the code) are limited
 to DVB-T, including Terratec Cinergy T XS, Pinnacle PCTV DVB-T,
 a couple KWorld 35xU DVB-T devices, and a Compro VideoMate.
 Apart from that, all remaining devices (apart from DMB and
 the like) appear to have the ability to handle analogue
 signals, and need USB2.0 to reach full potential.



 filtering in conjunction with USB 2.0.  The fix is really in response
 to users with older PCs trying to capture a full ATSC stream (or
 analog capture), and being *very* confused.  If there is really a
 concern that we should be supporting USB 1.1 ports, even though USB
 2.0 has been around for almost ten years, I guess I can add a modprobe
 option to allow the user to override the check.

 I actually have dredged from the dank dingy decaying dumpster
 depths or doom a machine fast enough to decode and display SD
 images, even without XVMC MPEG-2 acceleration, after replacing
 most of the electrolytic condensers/capacitors on the board, yet
 the internal USB ports are again 1.1.  Given all the Blinkenlights
 it's probably an ex-gamer machine, but compared with my machine
 at some 1/7 the CPU clock, it's not as obsolete as it could be,
 though that still doesn't stop me from periodically wanting to
 hurl it across the room every so

Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes

On Sat, May 23, 2009 at 4:07 PM, Markus Rechberger
mrechber...@gmail.com wrote:
 On Sat, May 23, 2009 at 4:00 PM, BOUWSMA Barry
 freebeer.bouw...@gmail.com wrote:
 Moin Devin, thanks for the reply.

 On Fri, 22 May 2009, Devin Heitmueller wrote:

 [cut my drivel]
 The dvb core does have infrastructure to support hardware pid
 filtering.

 If you don't mind, and this is a serious question, could you
 give me some keywords to look for?  I've come up with some
 obvious winners in dvb-usb with uppercase FILTER, but lowercase
 filter didn't give me any serious Aha! moments for other
 devices, in an attempt to determine device capabilities by
 simple code reading.  Thanks!  (And I'll gladly eat my shoes
 when it turns out to be something stupendously simple, as I'm
 no code-reader)


   I don't know too much about the DVB standards, but I know
 that ATSC is 19.39MB/s and QAM as deployed in US cable systems is
 about twice that.  Neither would fit in a 12Mbps stream.

 Bleedin' 'ell, I knew things were bigger in Texas, but I
 didn't know they wuz that big!  ;-)  Just kidding, I know
 what you meant...

 Just for background, the overall bandwidth of DVB-T will be
 determined by choice of frequency at one transmitter site or
 whether shared by several and how far apart, as well as other
 factors that are basically able to be simplified as a tradeoff
 of reliability over distance against bandwidth.  There's a wide
 variance here, but in even the most widely-reaching Single-
 Frequency-Networks that are meant to be received at large
 distances under difficult conditions, where available overall
 bandwidth is less than that of a single transmitter serving
 a local area, said overall bandwidth is generally going to
 exceed that which I've achieved from USB1.1.  A certain DVB-H
 network with 1/2 FEC and 1/4 guard interval drops below
 10 000kbit/sec but isn't likely to represent common usage
 for broadcast TV services.

 On the other hand, the individual services within each
 multiplex will generally be well within the USB1.1 available
 bandwidth, provided hardware PID filtering can be applied.
 Bitrates for television services can be from some 2Mbit/sec
 up to over 5Mbit/sec at times, depending on whether that
 service has been configured to get the lion's share of the
 bandwidth at the expense of the other services with rates
 dynamically varying based on picture content thanks to
 statistical multiplexing.

 In any case, while I've been able to watch average-per-second
 bitrates of different PIDs on different multiplexes, I've
 just realized that I haven't actually used any DVB-T
 receivers for any length of time on a USB1.1 port to see
 if instantaneous bursts will exceed that bandwidth, as is
 the case for quality services delivered via DVB-S and USB1.1.

 But I've read that it's the exception rather than the rule
 that a particular service will be privileged to get more
 than its proportional share of overall bandwidth, to be free
 of most artifacts and be watchable, so I'd be willing to posit
 that a full service (video, multiple audio, PMT, teletext, and
 the like) will fit onto USB1.1.

 So much for background.  Anyone still bothering to read?


 If I knew of a em2874/em2884 device that also didn't use the drx, I
 would consider it worthwhile to spend the time to do the work for the
 hardware filtering.  Until that happens though, I've got better things
 to spend my time on.

 No argument there.  I had a look through Herr Rechberger's
 code (simply because it's had a wider variety of included
 hardware, not to say anything about the linuxtv code) to get
 a feel for how many devices were exclusively DVB-T, or at
 least didn't include some baseband video.

 It appears that a group of EM2870 devices (may well be the
 2874 in reality, I just numbly scan the code) are limited
 to DVB-T, including Terratec Cinergy T XS, Pinnacle PCTV DVB-T,
 a couple KWorld 35xU DVB-T devices, and a Compro VideoMate.
 Apart from that, all remaining devices (apart from DMB and
 the like) appear to have the ability to handle analogue
 signals, and need USB2.0 to reach full potential.



 filtering in conjunction with USB 2.0.  The fix is really in response
 to users with older PCs trying to capture a full ATSC stream (or
 analog capture), and being *very* confused.  If there is really a
 concern that we should be supporting USB 1.1 ports, even though USB
 2.0 has been around for almost ten years, I guess I can add a modprobe
 option to allow the user to override the check.

 I actually have dredged from the dank dingy decaying dumpster
 depths or doom a machine fast enough to decode and display SD
 images, even without XVMC MPEG-2 acceleration, after replacing
 most of the electrolytic condensers/capacitors on the board, yet
 the internal USB ports are again 1.1.  Given all the Blinkenlights
 it's probably an ex-gamer machine, but compared with my machine
 at some 1/7 the CPU clock, it's not as obsolete as it could be,
 though that

Can't scan or add channels with new version of driver

2009-05-23 Thread Vladimir Geroy

Using driver v4l-dvb changeset befor 11017  
http://linuxtv.org/hg/v4l-dvb/rev/c2e9ae022ea7 my configuration work fine, but 
when I try to update for new version changeset 11018 or newly, I can't scan or 
add channels in all TV views or players.

My configuration:

Ubuntu 9.04 x86_64
Linux 2.6.28-11-generic
Compro VideoMate E650F


Work fine with the v4l-dvb changeset 11017  
http://linuxtv.org/hg/v4l-dvb/rev/c2e9ae022ea7

dmesg

[   13.400319] Linux video capture interface: v2.00
[   13.584724] cx23885 driver version 0.0.1 loaded
[   13.585254] ACPI: PCI Interrupt Link [APC8] enabled at IRQ 16
[   13.585266] cx23885 :04:00.0: PCI INT A - Link[APC8] - GSI 16 (level, 
low) - IRQ 16
[   13.585421] CORE cx23885[0]: subsystem: 1858:e800, board: Compro VideoMate 
E650F [card=13,insmod option]
[   13.661794] HDA Intel :00:09.0: power state changed by ACPI to D0
[   13.662212] ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22
[   13.662217] HDA Intel :00:09.0: PCI INT A - Link[AAZA] - GSI 22 
(level, low) - IRQ 22
[   13.662264] HDA Intel :00:09.0: setting latency timer to 64
[   13.769137] cx25840' 2-0044: cx25  0-21 found @ 0x88 (cx23885[0])
[   13.769936] cx23885_dvb_register() allocating 1 frontend(s)
[   13.769943] cx23885[0]: cx23885 based dvb card
[   13.836235] xc2028 1-0061: creating new instance
[   13.836241] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
[   13.836249] DVB: registering new adapter (cx23885[0])
[   13.836255] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)...
[   13.837169] cx23885_dev_checkrevision() Hardware revision = 0xb0
[   13.837180] cx23885[0]/0: found at :04:00.0, rev: 2, irq: 16, latency: 
0, mmio: 0xef60
[   13.837188] cx23885 :04:00.0: setting latency timer to 64

w_scan version 20081106
Info: using DVB adapter auto detection.
   Found DVB-T frontend. Using adapter /dev/dvb/adapter0/frontend0
-_-_-_-_ Getting frontend capabilities-_-_-_-_ 
frontend Zarlink ZL10353 DVB-T supports
INVERSION_AUTO
QAM_AUTO
TRANSMISSION_MODE_AUTO
GUARD_INTERVAL_AUTO
HIERARCHY_AUTO
FEC_AUTO
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 
177500: 
184500: 
191500: 
198500: 
205500: 
212500: 
219500: 
226500: 
474000: 
482000: 
49: 
498000: 
506000: 
514000: 
522000: 
53: 
538000: 
546000: 
554000: 
562000: 
57: 
578000: 
586000: 
594000: 
602000: 
61: 
618000: 
626000: 
634000: signal ok (I999B8C999D999M999T999G999Y999)
642000: 
65: signal ok (I999B8C999D999M999T999G999Y999)
658000: 
666000: 
674000: 
682000: 
69: 
698000: 
706000: 
714000: signal ok (I999B8C999D999M999T999G999Y999)
722000: 
73: 
738000: 
746000: 
754000: 
762000: 
77: 
778000: 
786000: 
794000: 
802000: 
81: 
818000: signal ok (I999B8C999D999M999T999G999Y999)
826000: 
834000: 
842000: 
85: 
858000: 
tune to: :634000:I999B8C999D999M999T999G999Y999:T:27500:
Network Name 'CONCERN RRT'
 UT-1(ERA PRODUCTION)
 K1(ERA PRODUCTION)
 RADA(ERA PRODUCTION)
 TV KYIV(ERA PRODUCTION)
tune to: :65:I999B8C999D999M999T999G999Y999:T:27500:
Network Name 'EXPRESS-INFORM'
copying transponder info (65)
 5 KANAL(KRRT)
 MEGASPORT(KRRT)
 TONIS(KRRT)
 OTV(KRRT)
 ICTV(KRRT)
tune to: :714000:I999B8C999D999M999T999G999Y999:T:27500:
Network Name 'UDTVN'
 MEGASPORT (TEST)(UDTVN)
 KULTURA (TEST)(UDTVN)
 INTER (TEST)(UDTVN)
 FOOTBALL (TEST)(UDTVN)
 M2 (TEST)(UDTVN)
 KDRTRK (TEST)(UDTVN)
 MUSICBOX (TEST)(UDTVN)
 TBi (TEST)(UDTVN)
 NTN(UDTVN)
 GUMOR TV (TEST)(UDTVN)
tune to: :818000:I999B8C999D999M999T999G999Y999:T:27500:
 GAMMA(GAMMA CONSULTING)
 M2(GAMMA CONSULTING)
 M1(GAMMA CONSULTING)
 RUMUSIC(GAMMA CONSULTING)
 NEWS_ONE(GAMMA CONSULTING)
Network Name 'Gamma consulting'
dumping lists (24 services)
UT-1:634000:I999B8C999D999M999T999G999Y999:T:27500:4111:4112=UKR:0:0:1:0:0:0
K1:634000:I999B8C999D999M999T999G999Y999:T:27500:4121:4122:0:0:2:0:0:0
RADA:634000:I999B8C999D999M999T999G999Y999:T:27500:4131:4132=ukr:0:0:3:0:0:0
TV KYIV:634000:I999B8C999D999M999T999G999Y999:T:27500:4141:4142:0:0:4:0:0:0
5 KANAL:65:I999B8C23D23M64T8G32Y0:T:27500:4311:4312=ukr:0:0:1:8259:43:0
MEGASPORT:65:I999B8C23D23M64T8G32Y0:T:27500:4321:4322:0:0:2:8259:43:0
TONIS:65:I999B8C23D23M64T8G32Y0:T:27500:4331+4339:4332:0:0:3:8259:43:0
OTV:65:I999B8C23D23M64T8G32Y0:T:27500:4341:4342:0:0:4:8259:43:0
ICTV:65:I999B8C23D23M64T8G32Y0:T:27500:4351:4352:0:0:5:8259:43:0
MEGASPORT 
(TEST):714000:I999B8C999D999M999T999G999Y999:T:27500:1011:1012=ukr:0:0:1:0:0:0
KULTURA 
(TEST):714000:I999B8C999D999M999T999G999Y999:T:27500:1021:1022=ukr:0:0:2:0:0:0
INTER 
(TEST):714000:I999B8C999D999M999T999G999Y999:T:27500:1031:1032=ukr:0:0:3:0:0:0
FOOTBALL 
(TEST):714000:I999B8C999D999M999T999G999Y999:T:27500:1041:1042=ukr:0:0:4:0:0:0
M2 
(TEST):714000:I999B8C999D999M999T999G999Y999:T:27500:1051:1052=ukr:0:0:5:0:0:0
KDRTRK 
(TEST):714000:I999B8C999D999M999T999G999Y999:T:27500:1061:1062=ukr:0:0:6:0:0:0
MUSICBOX

Re: [PATCH] em28xx device mode detection based on endpoints

Hi,

On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger
mrechber...@gmail.com wrote:
 On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger
 mrechber...@gmail.com wrote:
 Hi,

 for em28xx devices the device node detection can be based on the
 encoded endpoint address, for example EP 0x81 (USB IN, Interrupt),
 0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts input
 EP).
 It is not necessary that digital TV devices have a frontend, the
 em28xx chip only specifies an MPEG-TS input EP.

 Following patch adds a check based on the Endpoints, although it might
 be extended that all devices match the possible devicenodes based on
 the endpoints, currently the driver registers an analog TV node by
 default for all unknown devices which is not necessarily correct, this
 patch disables the ATV node if no analog TV endpoint is available.



attached patch fixes the deregistration, as well loads the em28xx-dvb
module automatically as soon as an MPEG-TS endpoint was found.

Signed-off-by: Markus Rechberger mrechber...@gmail.com

best regards,
Markus
diff -r 315bc4b65b4f linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c	Sun May 17 12:28:55 2009 +
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c	Sat May 23 17:03:00 2009 +0200
@@ -1596,9 +1596,13 @@
 /* Since em28xx_pre_card_setup() requires a proper dev-model,
  * this won't work for boards with generic PCI IDs
  */
-void em28xx_pre_card_setup(struct em28xx *dev)
+static int em28xx_pre_card_setup(struct em28xx *dev,
+struct usb_interface *intf)
 {
 	int rc;
+	int i;
+	struct usb_host_interface *host_interface = intf-altsetting[0];
+	int select_alt;
 
 	em28xx_set_model(dev);
 
@@ -1647,6 +1651,18 @@
 		}
 	}
 
+	/* this is for protecting wrong devices against the rest of the control
+	   commands
+	   for example:
+	   $ cd /sys/bus/usb/drivers/em28xx
+	   $ echo 1234 1234  new_id
+	*/
+
+
+	if (dev-model == EM2800_BOARD_UNKNOWN 
+		dev-chip_id = CHIP_ID_EM2883)
+		dev-lock_control_commands = 1;
+
 	/* Prepopulate cached GPO register content */
 	rc = em28xx_read_reg(dev, dev-reg_gpo_num);
 	if (rc = 0)
@@ -1658,8 +1674,66 @@
 	em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, dev-board.i2c_speed);
 	msleep(50);
 
+	if (dev-model != EM2800_BOARD_UNKNOWN)
+		/* defaulting to have the same behaviour as we always had */
+		dev-has_atv = 1;
+
 	/* request some modules */
 	switch (dev-model) {
+	case EM2800_BOARD_UNKNOWN:
+		if (dev-chip_id  CHIP_ID_EM2820) {
+			/* defaulting again .. */
+			dev-has_atv = 1;
+			break;
+		}
+
+		em28xx_info(Probing device modes (ignore all upcoming
+			 errors)\n);
+		em28xx_info(Found endpoints: %d\n,
+host_interface-desc.bNumEndpoints);
+		em28xx_info(Found alternate: %d\n, dev-num_alt);
+
+		switch (dev-num_alt) {
+		case 2:
+			select_alt = 1;
+			break;
+		case 8:
+			select_alt = 7;
+			break;
+		default:
+			/* guaranteed no EETI TV device */
+			return -EINVAL;
+		}
+		for (i = 0; i  host_interface-desc.bNumEndpoints; i++) {
+			em28xx_info(Alternate setting %d [%02x]\n,
+select_alt,
+intf-altsetting[select_alt].endpoint[i].
+	desc.bEndpointAddress);
+
+			switch (intf-altsetting[select_alt].endpoint[i].
+desc.bEndpointAddress) {
+			case EM28XX_INTERRUPT_EP:
+/* currently not implemented */
+break;
+			case EM28XX_ANALOG_VIDEO_EP:
+/* registered by default already which
+   is bogus */
+em28xx_info(FOUND ATV EP\n);
+dev-has_atv = 1;
+break;
+			case EM28XX_ANALOG_AUDIO_EP:
+em28xx_info(Found PCMAUDIO EP\n);
+dev-has_alsa_audio = 1;
+break;
+			case EM28XX_DIGITALTV_EP:
+em28xx_info(Found MPEG-TS EP\n);
+dev-has_dvb = 1;
+break;
+			default:
+return -EINVAL;
+			}
+		}
+		break;
 	case EM2861_BOARD_PLEXTOR_PX_TV100U:
 		/* FIXME guess */
 		/* Turn on analog audio output */
@@ -1748,6 +1822,7 @@
 
 	/* Unlock device */
 	em28xx_set_mode(dev, EM28XX_SUSPEND);
+	return 0;
 }
 
 static void em28xx_setup_xc3028(struct em28xx *dev, struct xc2028_ctrl *ctl)
@@ -2119,7 +2194,7 @@
 	else if (dev-has_alsa_audio)
 		request_module(em28xx-alsa);
 
-	if (dev-board.has_dvb)
+	if (dev-board.has_dvb || dev-has_dvb)
 		request_module(em28xx-dvb);
 }
 
@@ -2191,8 +2266,12 @@
 	dev-em28xx_write_regs_req = em28xx_write_regs_req;
 	dev-em28xx_read_reg_req = em28xx_read_reg_req;
 	dev-board.is_em2800 = em28xx_boards[dev-model].is_em2800;
+	dev-has_dvb = dev-board.has_dvb;
 
-	em28xx_pre_card_setup(dev);
+	retval = em28xx_pre_card_setup(dev, interface);
+
+	if (retval)
+		return retval;
 
 	if (!dev-board.is_em2800) {
 		/* Sets I2C speed to 100 KHz */
@@ -2265,16 +2344,19 @@
 
 	em28xx_add_into_devlist(dev);
 
-	retval = em28xx_register_analog_devices(dev);
-	if (retval  0) {
-		em28xx_release_resources(dev);
-		goto fail_reg_devices;
+	if (dev-has_atv) {
+		retval = em28xx_register_analog_devices(dev);
+		if (retval  0) {
+			em28xx_release_resources(dev);
+			goto fail_reg_devices;
+		}
 	}

cannot rmmod stb0899

2009-05-23 Thread Andreas Besse


Hello,

I'm using a KNC One TV-Station DVB-S2 Plus and a WinTV-NOVA-CI PCI with
the multiprotocol drivers from http://www.jusst.de/hg/multiproto/
(changeset: 7218:2a911b8f9910, date: Wed Jul 09 23:07:29 2008 +0400)

The drivers run fine since 250 (!) days, but I have an issue with high
cpu load. So I decited to apply the patch Fix High CPU load in 'top'
due to budget_av slot polling from Oliver Endriss or try the current
v4l tree.

First i tried to remove the current drivers. If i call rmmod stb0899
the driver is not removed. Instead an Error ERROR: Module stb0899 is in
use is shown (but no application is using the device)

I also tried rmmod -w stb0899. This leads to an infinite loop and I'm
not able to kill the process.

How can I rmmod the stb0899 driver without rebooting the system?

How can I kill rmmod -w stb0899?

regards,
Andreas Besse

===

output of lsmod:
...
tsdev   7968  0
budget_av  24192  1
saa7146_vv 45152  2 budget_av
videobuf_dma_sg12996  1 saa7146_vv
videobuf_core  17252  2 saa7146_vv,videobuf_dma_sg
videodev   26528  2 saa7146_vv
v4l2_common17216  2 saa7146_vv,videodev
v4l1_compat12516  2 saa7146_vv,videodev
firmware_class  9504  2 budget_ci,budget_av
budget_core10756  2 budget_ci,budget_av
dvb_core   79900  4 budget_ci,stv0299,budget_av,budget_core
saa714618248  4 budget_ci,budget_av,saa7146_vv,budget_core
ttpci_eeprom2432  1 budget_core
ide_cd 36416  0
cdrom  32832  1 ide_cd
rtc12856  0
pcspkr  3104  0
intel_agp  23188  1
i2c_i8018656  0
i2c_core   23552  10
budget_ci,stv0299,i2c_isa,tda8261,stb0899,budget_av,v4l2_common,budget_core,ttpci_eeprom,i2c_i801


===

output of make rmmod in multiprotocol directory:

Mail:~/pakete/multiproto# make rmmod
make -C /root/pakete/multiproto/v4l rmmod
make[1]: Entering directory `/root/pakete/multiproto/v4l'
scripts/rmmod.pl unload
found 230 modules
/sbin/rmmod budget_av
ERROR: Module budget_av is in use
/sbin/rmmod budget_ci
/sbin/rmmod saa7146_vv
ERROR: Module saa7146_vv is in use by budget_av
/sbin/rmmod videodev
ERROR: Module videodev is in use by saa7146_vv
/sbin/rmmod budget_core
ERROR: Module budget_core is in use by budget_av
/sbin/rmmod stv0299
/sbin/rmmod videobuf_dma_sg
ERROR: Module videobuf_dma_sg is in use by saa7146_vv
/sbin/rmmod stb0899
ERROR: Module stb0899 is in use
/sbin/rmmod v4l1_compat
ERROR: Module v4l1_compat is in use by saa7146_vv,videodev
/sbin/rmmod dvb_core
ERROR: Module dvb_core is in use by budget_av,budget_core
/sbin/rmmod tda8261
ERROR: Module tda8261 is in use
/sbin/rmmod v4l2_common
ERROR: Module v4l2_common is in use by saa7146_vv,videodev
/sbin/rmmod videobuf_core
ERROR: Module videobuf_core is in use by saa7146_vv,videobuf_dma_sg
/sbin/rmmod ir_common
/sbin/rmmod saa7146
ERROR: Module saa7146 is in use by budget_av,saa7146_vv,budget_core
/sbin/rmmod ttpci_eeprom
ERROR: Module ttpci_eeprom is in use by budget_core
/sbin/rmmod budget_av
ERROR: Module budget_av is in use
/sbin/rmmod saa7146_vv
ERROR: Module saa7146_vv is in use by budget_av
/sbin/rmmod videodev
ERROR: Module videodev is in use by saa7146_vv
/sbin/rmmod budget_core
ERROR: Module budget_core is in use by budget_av
/sbin/rmmod videobuf_dma_sg
ERROR: Module videobuf_dma_sg is in use by saa7146_vv
/sbin/rmmod stb0899
ERROR: Module stb0899 is in use
/sbin/rmmod v4l1_compat
ERROR: Module v4l1_compat is in use by saa7146_vv,videodev
/sbin/rmmod dvb_core
ERROR: Module dvb_core is in use by budget_av,budget_core
/sbin/rmmod tda8261
ERROR: Module tda8261 is in use
/sbin/rmmod v4l2_common
ERROR: Module v4l2_common is in use by saa7146_vv,videodev
/sbin/rmmod videobuf_core
ERROR: Module videobuf_core is in use by saa7146_vv,videobuf_dma_sg
/sbin/rmmod saa7146
ERROR: Module saa7146 is in use by budget_av,saa7146_vv,budget_core
/sbin/rmmod ttpci_eeprom
ERROR: Module ttpci_eeprom is in use by budget_core
Couldn't unload: ttpci_eeprom saa7146 videobuf_core v4l2_common tda8261
dvb_core v4l1_compat stb0899 videobuf_dma_sg budget_core videodev
saa7146_vv budget_av
make[1]: Leaving directory `/root/pakete/multiproto/v4l'

===

lsmod after make rmmod

budget_av  24192  1
saa7146_vv 45152  2 budget_av
videobuf_dma_sg12996  1 saa7146_vv
videobuf_core  17252  2 saa7146_vv,videobuf_dma_sg
videodev   26528  2 saa7146_vv
v4l2_common17216  2 saa7146_vv,videodev
v4l1_compat12516  2 saa7146_vv,videodev
firmware_class  9504  1 budget_av
budget_core10756  1 budget_av
dvb_core   79900  2 budget_av,budget_core
saa714618248  3 budget_av,saa7146_vv,budget_core
ttpci_eeprom

Re: [linux-dvb] Most stable DVB-S2 PCI Card?

2009-05-23 Thread Andreas Regel


David Lister schrieb:

I didn't want to write a long mail, but here goes:

The TechnoTrend company, as of Februay 2009, doesn't exists any more.
*It is bankrupt*. First, its owner Novabase sold as many of its shares
as it could in 2007, in hope that the proceeds would allow TechnoTrend
to get back on track. No such luck. A few months back this year, the
company was finally dumped and sold as a whole to some German telco
company in the Kathrein Group for liquidation, because of the tremendous
drop in it's market value and forthcoming bankruptcy. This might also be
of some interest to prospective buyers of it's former products. :) I
don't want to search for all the press releases, but you can verify this
claim here:
http://www.euronext.com/fic/000/044/480/444806.pdf


As written there the Görler Telekom bought the business and stock of TT, 
that includes the brand name, all products and most of the developers. 
They formed a new Company called TechnoTrend Görler GmbH, that will 
continue development, production and sales.


See here: http://www.kathrein.de//en/press/cont/texte2009/pi0910.htm

Even if not explicitely mentioned there, PC products are included in 
that deal.


New web site is still under construction: http://www.ttgoerler.de/

Regards
Andreas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about driver for Mantis

2009/5/23 David Lister foc...@gmail.com:
 Gernot Pansy wrote:
 will CI be supported and are you willing to finish development and merge it 
 to
 mainline anytime?

 i think i was one of the first SP400 owner but i had to sold my card for a 
 Nova
 HD2 because the driver was not reliable (some i2c errors, slow tunning,
 sometimes tunning failed). And now i need a dvb-s2 card with ci working. so
 i'm searching again for a new card. their seems to be only the tt-3200 out,
 which seems to work - no newer card.

 Not sure if you didn't get this email already, I had a slip-up while
 sending it. :) Anyway, there's also another supported card with a CI. A
 friend of mine has it, so I guess it works quite well with Linux. It's
 Mystique SaTiX-S2 (AFAIK, similar to KNC1+). Mystiques have rather
 quality finish and the CI module is ready for 3.5 drive installation.
 Some pictures from google:

 http://www.cesarex.com/images/Mystique-CI-1.jpg
 http://www.sat-servis.cz/data/eshop/fotky/produkty/velke/619.jpg

 Others might be able to tell you more details, I just know it works -
 friend has a Cryptoworks CAM in it. Take a look around, bye.

The Mystique is just a rebranded KNC1+ which just uses the same
STB0899 module, FYI. :-)

Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about driver for Mantis

2009-05-23 Thread Jarosław Huba

I will also look for vanilla kernel.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Most stable DVB-S2 PCI Card?

Andreas Regel wrote:
 David Lister schrieb:
 I didn't want to write a long mail, but here goes:

 The TechnoTrend company, as of Februay 2009, doesn't exists any more.
 *It is bankrupt*. First, its owner Novabase sold as many of its shares
 as it could in 2007, in hope that the proceeds would allow TechnoTrend
 to get back on track. No such luck. A few months back this year, the
 company was finally dumped and sold as a whole to some German telco
 company in the Kathrein Group for liquidation, because of the tremendous
 drop in it's market value and forthcoming bankruptcy. This might also be
 of some interest to prospective buyers of it's former products. :) I
 don't want to search for all the press releases, but you can verify this
 claim here:
 http://www.euronext.com/fic/000/044/480/444806.pdf

 As written there the Görler Telekom bought the business and stock of
 TT, that includes the brand name, all products and most of the
 developers. They formed a new Company called TechnoTrend Görler GmbH,
 that will continue development, production and sales.

 See here: http://www.kathrein.de//en/press/cont/texte2009/pi0910.htm

 Even if not explicitely mentioned there, PC products are included in
 that deal.

 New web site is still under construction: http://www.ttgoerler.de/

That is good news, thanks for the update! Everything falling apart last
time I checked was a rather disturbing experience, even though I've
never been their greatest fan. There's just a handful of companies
making usable PC tuners and TT was one of the bigger ones. If KG are
serious, I am quite relieved. Kathrein not only has extensive know-how
and capital, it seems to like Linux. We might even see official Linux
support for their new products. That would be cool! :) I'd definitely
support such a manufacturer.

*OT* I just remembered in connection with Linux DVB-S2 cards: in case
some of you also heard about that new dual DVB-S2-CI tuner for PC's with
full Linux support, you can forget about it. Or at least I can. When I
pre-ordered directly from the Russian manufacturer (NetUP), they said
the price for one would be $1000. What a rip-off...

-- 
Dave
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down

2009-05-23 Thread David

Alan Stern wrote:
 On Sat, 23 May 2009, Pekka Enberg wrote:

   
 On Sat, May 23, 2009 at 12:32 AM, David da...@unsolicited.net wrote:
 
 I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
 finally had time to do some digging, and the regression is caused by:

b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci-hcd unlink speedups

 ..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5
 makes the card work happily again.
   
 [ Note: David meant 2.6.30-rc5 here. ]

 Thanks for doing the bisect!

 On Sat, May 23, 2009 at 12:32 AM, David da...@unsolicited.net wrote:
 
 I don't know enough about USB protocols to speculate on whether there
 may be a better fix, but hopefully someone cleverer than me can get to
 the bottom of the problem?
   

 It's hard to see how that patch could cause any problems, provided the
 hardware is working correctly.  (There was a case where the hardware
 was _not_ working as expected.)  Is any more information available
 about this failure?
   
Here's all I have. The device is a USB connected Technotrend TT-Connect
S-2400. Support for this was added in kernel 2.6.26. When I came to
upgrade my media PC beyond .26 the dmesg showed the following:-

Media PC (32-bit - Nvidia chipset. kernel 2.6.27)

19:13:18 s kernel: usb 1-3: new high speed USB device using ehci_hcd and
address 6
19:13:18 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:13:18 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in
cold state, will try to load a firmware
19:13:18 s kernel: firmware: requesting dvb-usb-tt-s2400-01.fw
19:13:18 s kernel: dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
19:13:18 s kernel: usb 1-3: USB disconnect, address 6
19:13:18 s kernel: dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
19:13:20 s kernel: usb 1-3: new high speed USB device using ehci_hcd and
address 7
19:13:20 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:13:20 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in
warm state.
19:13:20 s kernel: dvb-usb: will pass the complete MPEG2 transport
stream to the software demuxer.
19:13:20 s kernel: DVB: registering new adapter (Technotrend TT-connect
S-2400)
19:13:20 s kernel: DVB: registering frontend 0 (Philips TDA10086 DVB-S)...
19:13:23 s kernel: dvb-usb: recv bulk message failed: -110
19:13:23 s kernel: ttusb2: there might have been an error during control
message transfer. (rlen = 0, was 0)
19:13:23 s kernel: dvb-usb: Technotrend TT-connect S-2400 successfully
initialized and connected.

The device times out. Reverting b963801164618e25fbdc0cd452ce49c3628b46c8
causes it to work again

19:09:53 s kernel: usb 1-3: new high speed USB device using ehci_hcd and
address 5
19:09:53 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:09:58 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in
cold state, will try to load a firmware
19:09:58 s kernel: firmware: requesting dvb-usb-tt-s2400-01.fw
19:09:59 s kernel: dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
19:09:59 s kernel: usb 1-3: USB disconnect, address 5
19:09:59 s kernel: dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
19:09:59 s kernel: usbcore: registered new interface driver dvb_usb_ttusb2
19:10:00 s kernel: usb 1-3: new high speed USB device using ehci_hcd and
address 6
19:10:00 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:10:01 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in
warm state.
19:10:01 s kernel: dvb-usb: will pass the complete MPEG2 transport
stream to the software demuxer.
19:10:01 s kernel: DVB: registering new adapter (Technotrend TT-connect
S-2400)
19:10:01 s kernel: DVB: registering frontend 3 (Philips TDA10086 DVB-S)...
19:10:01 s kernel: dvb-usb: Technotrend TT-connect S-2400 successfully
initialized and connected.

My PC (64 bit - ATI chipset, using 2.6.30-rc5)

[12044.364021] usb 4-10: new high speed USB device using ehci_hcd and
address 5
[12044.497561] usb 4-10: configuration #1 chosen from 1 choice
[12044.881621] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold
state, will try to load a firmware
[12044.881626] usb 4-10: firmware: requesting dvb-usb-tt-s2400-01.fw
[12044.918854] dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
[12044.980719] usbcore: registered new interface driver dvb_usb_ttusb2
[12044.981478] usb 4-10: USB disconnect, address 5
[12044.985169] dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
[12046.744023] usb 4-10: new high speed USB device using ehci_hcd and
address 6
[12046.876980] usb 4-10: configuration #1 chosen from 1 choice
[12046.877673] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm
state.
[12046.878601] dvb-usb: will pass the complete MPEG2 transport stream to
the software demuxer.
[12046.878959] DVB: registering new adapter (Technotrend TT-connect S-2400)
[12046.886861] DVB:

Re: [PATCH 1/5 - part 2] V4L2 patches for Intel Moorestown Camera Imaging Drivers

2009-05-23 Thread Trent Piepho

On Sat, 23 May 2009, Mauro Carvalho Chehab wrote:
  + + if (intel-open) { + ++intel-open; + DBG_DD((device has opened
  already - %d\n, intel-open)); + return 0; + } + + file-private_data
  = dev; + /* increment our usage count for the driver */ +
  ++intel-open; + DBG_DD((intel_open is %d\n, intel-open)); +

 Open is not the proper place to clean the configuration, since a V4L2
 device should support more than one open.  You can use a different
 userspace app to control your device, while other application is
 streaming it.

It looks like only the first open will set the configuration, subsequent
ones don't do anything.  So maybe this driver is ok for multiple opens?
Doesn't the kernel make open and close atomic, so some kind of barrier or
atomic variable isn't necessary?

  +static int intel_g_fmt_cap(struct file *file, void *priv,
  +   struct v4l2_format *f)
  +{
  +   struct video_device *dev = video_devdata(file);
  +   struct intel_isp_device *intel = video_get_drvdata(dev);
  +   int ret;
  +
  +   DBG_DD((intel_g_fmt_cap\n));
  +   if (f-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {

Once switched to video-ioctl2, it don't be necessary to check the type of
buffer.  vidioc_g_fmt_cap will only be called with video capture buffers.
It's the same with all the other vidioc_*_cap methods.

  +static int intel_s_input(struct file *file, void *priv, unsigned int i)
  +{
  +   return 0;
  +}

Wouldn't it be better to return an error if the input is something other
than zero?

  +   snrcfg = intel-sys_conf.isi_config;
  +   index = f-index;
  +
  +   if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
  +   ret = -EINVAL;
  +   else {
  +   if (snrcfg-type == SENSOR_TYPE_SOC)
  +   if (index = 8)
  +   return -EINVAL;
  +   if (index = sizeof(fmts) / sizeof(*fmts))
  +   return -EINVAL;
  +   memset(f, 0, sizeof(*f));
  +   f-index = index;

Saving index, clearing f, and restoring index isn't necessary.
video-ioctl2 will take care of clearing everything that needs to be
cleared.

  +   f-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;

Not necessary either, you already know type is set correctly.

  +   if (buf-memory != V4L2_MEMORY_MMAP ||
  +   buf-type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
  +   buf-index = intel-num_frames || buf-index  0)
  +   return  -EINVAL;

You don't need to check buf-type, it will be a type your driver supports.
buf-index is unsigned, obviously it can't be less than zero.  The same
applies to all the other buffer functions.  Looks like you copied from old
code.  Some drivers had these unnecessary checks but they should have all
been cleaned up by now.

  +   pci_read_config_word(dev, PCI_VENDOR_ID, intel-vendorID);
  +   pci_read_config_word(dev, PCI_DEVICE_ID, intel-deviceID);

Do you ever use these after saving them?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about driver for Mantis

2009/5/23 Jarosław Huba jarhu...@poczta.onet.pl

  Just clone the tree on to your machine
  hg clone http://jusst.de/hg/mantis-v4l
 
  Clean stal remnants if any.
  make distclean
 
  Build the tree
  make
 

 I got this error:
 ja...@jarek-desktop:~/mantis-v4l$ make
 make -C /home/jarek/mantis-v4l/v4l
 make[1]: Wejście do katalogu `/home/jarek/mantis-v4l/v4l'
 No version yet, using 2.6.30-6-generic
 make[1]: Opuszczenie katalogu `/home/jarek/mantis-v4l/v4l'
 make[1]: Wejście do katalogu `/home/jarek/mantis-v4l/v4l'
 scripts/make_makefile.pl
 Updating/Creating .config
 Preparing to compile for kernel version 2.6.30

 ***WARNING:*** You do not have the full kernel sources installed.
 This does not prevent you from building the v4l-dvb tree if you have the
 kernel headers, but the full kernel source may be required in order to use
 make menuconfig / xconfig / qconfig.

 If you are experiencing problems building the v4l-dvb tree, please try
 building against a vanilla kernel before reporting a bug.

 Vanilla kernels are available at http://kernel.org.
 On most distros, this will compile a newly downloaded kernel:

 cp /boot/config-`uname -r` your kernel dir/.config
 cd your kernel dir
 make all modules_install install

 Please see your distro's web site for instructions to build a new kernel.

 Created default (all yes) .config file
 ./scripts/make_myconfig.pl
 make[1]: Opuszczenie katalogu `/home/jarek/mantis-v4l/v4l'
 make[1]: Wejście do katalogu `/home/jarek/mantis-v4l/v4l'
 perl scripts/make_config_compat.pl /lib/modules/2.6.30-6-generic/build
 ./.myconfig ./config-compat.h
 creating symbolic links...
 ln -sf . oss
 Kernel build directory is /lib/modules/2.6.30-6-generic/build
 make -C /lib/modules/2.6.30-6-generic/build SUBDIRS=/home/jarek/mantis-v4l/v4l
 modules
 make[2]: Entering directory `/usr/src/linux-headers-2.6.30-6-generic'
  CC [M]  /home/jarek/mantis-v4l/v4l/tuner-xc2028.o
  CC [M]  /home/jarek/mantis-v4l/v4l/tuner-simple.o
  CC [M]  /home/jarek/mantis-v4l/v4l/tuner-types.o
  CC [M]  /home/jarek/mantis-v4l/v4l/mt20xx.o
  CC [M]  /home/jarek/mantis-v4l/v4l/tda8290.o
  CC [M]  /home/jarek/mantis-v4l/v4l/tea5767.o
  CC [M]  /home/jarek/mantis-v4l/v4l/tea5761.o
  CC [M]  /home/jarek/mantis-v4l/v4l/tda9887.o
  CC [M]  /home/jarek/mantis-v4l/v4l/tda827x.o
  CC [M]  /home/jarek/mantis-v4l/v4l/au0828-core.o
  CC [M]  /home/jarek/mantis-v4l/v4l/au0828-i2c.o
  CC [M]  /home/jarek/mantis-v4l/v4l/au0828-cards.o
 In file included from /home/jarek/mantis-v4l/v4l/dmxdev.h:33,
                 from /home/jarek/mantis-v4l/v4l/au0828.h:29,
                 from /home/jarek/mantis-v4l/v4l/au0828-cards.c:22:
 /home/jarek/mantis-v4l/v4l/compat.h:396: error: redefinition of
 'usb_endpoint_type'
 include/linux/usb/ch9.h:376: note: previous definition of 'usb_endpoint_type'
 was here

Quick fix, do a make menuconfig: navigate through the menus, disable
au0828 support and try again.

Regards,
Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about driver for Mantis

On Sat, May 23, 2009 at 9:42 PM, David Lister foc...@gmail.com wrote:
 Manu Abraham wrote:
 2009/5/23 David Lister foc...@gmail.com:

 Not sure if you didn't get this email already, I had a slip-up while
 sending it. :) Anyway, there's also another supported card with a CI. A
 friend of mine has it, so I guess it works quite well with Linux. It's
 Mystique SaTiX-S2 (AFAIK, similar to KNC1+). Mystiques have rather
 quality finish and the CI module is ready for 3.5 drive installation.
 Some pictures from google:

 http://www.cesarex.com/images/Mystique-CI-1.jpg
 http://www.sat-servis.cz/data/eshop/fotky/produkty/velke/619.jpg

 Others might be able to tell you more details, I just know it works -
 friend has a Cryptoworks CAM in it. Take a look around, bye.


 The Mystique is just a rebranded KNC1+ which just uses the same
 STB0899 module, FYI. :-)

 Not exactly. People usually say it is a rebrand/clone of KNC1+, but it's
 not. :) There are couple of differences -- Mystique is a lighter version
 missing these features:
 1) Signal passthrough via loop-out connector
 2) Video input port for analogue capture

 I'm glad you reminded me of this misconception, the differences might be
 important for somebody. I was considering Mystique for myself, but chose
 CX24116 over STB0899, because this time, I wanted official support. I
 don't need analogue capture and CI anyway (I use softcam and for analog,
 much better Hauppauge PVR-500). I suggest Mystique instead of KNC1+ for
 purely practical reasons - it's more available, cheaper and nicer. :)


No misconceptions:


So support for it just appeared like magic ?

There are 2 card variants:

1. KNC1
a) KNC1 DVB-S2+ (With analog support)
b) KNC1 DVB-S2 (without analog support, the board has the place to
solder the SAA7113, just that no chip and connectors)

2. Satelco

Satelco DVB-S2 KNC1 (OEM clone of b)

3. Mystique

CI uses polling model in all the above 3.

Mystique (clone of KNC1 either A or B, even subsystem ID's itself
aren't different, AFAICS)



Now, there are other STB0899 based cards:

4. TT S2 3200

Very similar to the ST reference design. Uses a SAA7146 for the PCI bridge
CI uses an interrupt driven model.

5. VP-1041

Very similar to the ST reference design. Uses a Mantis PCI bridge.

CI is using a much different model. CI slot supports raw PCMCIA devices as well.
currently CI support is very preliminary and not much functional.

HTH
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Most stable DVB-S2 PCI Card?

On Sat, May 23, 2009 at 10:16 PM, David Lister foc...@gmail.com wrote:
 Andreas Regel wrote:
 David Lister schrieb:
 I didn't want to write a long mail, but here goes:

 The TechnoTrend company, as of Februay 2009, doesn't exists any more.
 *It is bankrupt*. First, its owner Novabase sold as many of its shares
 as it could in 2007, in hope that the proceeds would allow TechnoTrend
 to get back on track. No such luck. A few months back this year, the
 company was finally dumped and sold as a whole to some German telco
 company in the Kathrein Group for liquidation, because of the tremendous
 drop in it's market value and forthcoming bankruptcy. This might also be
 of some interest to prospective buyers of it's former products. :) I
 don't want to search for all the press releases, but you can verify this
 claim here:
 http://www.euronext.com/fic/000/044/480/444806.pdf

 As written there the Görler Telekom bought the business and stock of
 TT, that includes the brand name, all products and most of the
 developers. They formed a new Company called TechnoTrend Görler GmbH,
 that will continue development, production and sales.

 See here: http://www.kathrein.de//en/press/cont/texte2009/pi0910.htm

 Even if not explicitely mentioned there, PC products are included in
 that deal.

 New web site is still under construction: http://www.ttgoerler.de/

 That is good news, thanks for the update! Everything falling apart last
 time I checked was a rather disturbing experience, even though I've
 never been their greatest fan. There's just a handful of companies
 making usable PC tuners and TT was one of the bigger ones. If KG are
 serious, I am quite relieved. Kathrein not only has extensive know-how
 and capital, it seems to like Linux. We might even see official Linux
 support for their new products. That would be cool! :) I'd definitely
 support such a manufacturer.

 *OT* I just remembered in connection with Linux DVB-S2 cards: in case
 some of you also heard about that new dual DVB-S2-CI tuner for PC's with
 full Linux support, you can forget about it. Or at least I can. When I
 pre-ordered directly from the Russian manufacturer (NetUP), they said
 the price for one would be $1000. What a rip-off...

Indeed it is.

Maybe you will get a DVB card with dual DVB-S2 and CI with hardware
H.264 decoder and HDMI out for a better deal. You might need to wait for
the hardware to be available though.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about driver for Mantis

Manu Abraham wrote:
 On Sat, May 23, 2009 at 9:42 PM, David Lister foc...@gmail.com wrote:
   
 Manu Abraham wrote:
 
 2009/5/23 David Lister foc...@gmail.com:

   
 Not sure if you didn't get this email already, I had a slip-up while
 sending it. :) Anyway, there's also another supported card with a CI. A
 friend of mine has it, so I guess it works quite well with Linux. It's
 Mystique SaTiX-S2 (AFAIK, similar to KNC1+). Mystiques have rather
 quality finish and the CI module is ready for 3.5 drive installation.
 Some pictures from google:

 http://www.cesarex.com/images/Mystique-CI-1.jpg
 http://www.sat-servis.cz/data/eshop/fotky/produkty/velke/619.jpg

 Others might be able to tell you more details, I just know it works -
 friend has a Cryptoworks CAM in it. Take a look around, bye.

 
 The Mystique is just a rebranded KNC1+ which just uses the same
 STB0899 module, FYI. :-)

   
 Not exactly. People usually say it is a rebrand/clone of KNC1+, but it's
 not. :) There are couple of differences -- Mystique is a lighter version
 missing these features:
 1) Signal passthrough via loop-out connector
 2) Video input port for analogue capture

 I'm glad you reminded me of this misconception, the differences might be
 important for somebody. I was considering Mystique for myself, but chose
 CX24116 over STB0899, because this time, I wanted official support. I
 don't need analogue capture and CI anyway (I use softcam and for analog,
 much better Hauppauge PVR-500). I suggest Mystique instead of KNC1+ for
 purely practical reasons - it's more available, cheaper and nicer. :)
 
 No misconceptions:
   
Oh, but there are. We were both talking about the sat version of KNC1+,
not KNC1! You said and I quote: The Mystique is just a rebranded
KNC1+, which is not true. That's why I originally said that it's
*similar* to Mystique, which *is* true. It might be the same as plain
KNC1 or dozens of other rebranded versions, but that wasn't the point.
The misconception is that Mystique is KNC1+ clone -- it is not.
Perhaps I could have mentioned basic TV Station DVB-S too, but I didn't
expect I'll have to defend every word I say. Now that I think about it,
I'm glad I didn't - your inability to comprehend the simplest of
meanings shines like the sun.

Your follow-up comment was completely useless, arbitrary trolling. If
you could face the life like a man instead of a cry baby, you wouldn't
have the need to patronise me (unsuccessfully:)) in an unrelated thread
just because of our earlier argument. You should be ashamed of yourself.
You're a DVB driver developer and you have a hard time arguing with
somebody who has seen DVB-S for the first time in his life a month ago!


 So support for it just appeared like magic ?
   
Were you arguing with one of your other personalities in your head that
I missed something? I'm afraid you are a bit confused today, or you
misinterpret the meaning of my words on purpose, or are just pissed off
at me. :) Whatever. Because it might be your weak English, I'm not going
to call you an idiot like you called me a few times today, even though
this time it *would* be appropriate. It's the same thing as in the other
thread all over again. It's impossible to have a normal intelligent
conversation with you. I'm not going to support your trolling any more.

As usual, I wish you good luck in your efforts. Looks like you need it.

-- 
Dave
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Most stable DVB-S2 PCI Card?