Jean, you're a hero
it works thanks, Richard if you need any data about your patch I will be available for testing On Tue, 2008-08-19 at 22:08 +0200, Jean Delvare wrote: > Hi Martin, Richard, > > On Tue, 19 Aug 2008 21:41:21 +0200, Martin Samuelsson wrote: > > On Tue, 19 Aug 2008 12:58:16 +0200 > > richard <[EMAIL PROTECTED]> wrote: > > > > > Hello, > > > > > > I'm using multiple (3 now) dc10plus cards for doing live video shows as > > > > I've got a Buz, a 6 Eyes and a DC10+ in mine. > > > > > So everything works fine > > > except for the dc10plus cards > > > They are not always initialized correctly, so sometimes I have two > > > sometimes one and sometimes three cards working. > > > > I can imagine that. I have similar problems, but I'm a little surprised > > your system works as good as it does. > > > > > It might have something to do with the order in which the cards are > > > initialized when all cards are found first an then initialized it seems > > > to work, but when a card is initialized before other cards are found > > > then there is an error. > > > > That is most likely the problem, yes. If you dig at the really low > > levels in the initialization routines, you'll probably find out that > > the video encoders and decoders are initialized at least nine times > > each per card, due to some peculiarities concerning the interaction > > between i2c buses and i2c devices. > > Not sure what you mean with "initialized". I fail to see how a given > decoder or encoder could be initialized more than once, given that the > address becomes busy once an i2c client is attached. > > The main problem of the current code is when mixing different types of > zoran adapters. I don't expect that many problems when several adapters > of the same type (i.e. using the same encoder and decoder) are used. > > > In short, the kernel should see each encoder and decoder once for every > > i2c bus on each of the cards, but as things are now, all of them are > > visible, without any buses differentiating them. > > > > If this is the culprit, it has been identified, and is being worked on > > by Jean Delvare. I don't know what the time table looks like; there's > > quite a bit of fiddling involved. > > Actually I'm done with the conversion now, and would welcome testers. > I'm attaching a (relatively large) patch against 2.6.27-rc3, which > converts the whole zoran driver set to the new i2c device binding model. > With this conversion, each zoran adapter will explicitly instantiate its > I2C encoder and decoder devices. No more probing and guessing. > > I would like to head feedback from testers. In particular: > * I want to be sure that the patch doesn't break existing working > setups. > * If the patch solves problems, I'd like to know. One thing for sure > is that driver loading should be somewhat faster. > > Note that the patch won't work with kernels older than 2.6.27-rc1. > > > > > You _might_ be helped by manually modprobing the encoder and decoder > > drivers before zr63060. > > > > Follow-up question: Are you using the on-board composite output > > connector? My DC10+ stops after a number of frames when playing with > > lavplay -pC, stalling waiting for a buffer. I've reduced it to some > > kind of race condition, but I'm not sure where to go from there, or > > if indeed any other DC10+ users than me experience the problem. > > I don't think I ever used my DC10+ output channels, sorry. > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
