On Mon, 2003-05-05 at 04:30, Tom Zoerner wrote: > Hi Richard, > > > Changing it back caused correct field order for me on my flyvideo > > 3000. > > Could you please let us know how you get to the conclusion that field > order is wrong? > CNN text crawler has classic field order jitter. Lips on speakers likewise. Fast movement also shows bad jitter. Scene changes appear to flick back briefly to the previous scene during scene change. > > The person who the test with 0x00 worked for mentioned that it was > > only a workaround, as the new behaviour clashes with the > > documentation for the chip. > > You're probably referring to me. I originally proposed this workaround > for VBI, because without it data streams are completely garbled due to > swapped field order. I'm using the fix with a Typhoon TV+Radio 90031 > (SAA7134) since Mar/11/2003. > Ok, I'm using a FlyVideo 3000 purchased a couple of weeks ago, the board has a revision number on it but I can't grab it right now. > To investigate the problem I also did write magic words into the DMA > buffer in the first line of each field and checked in each interrupt > which one was overwritten. This did confirm the reverse semantics of > DMA status bits. > Interesting, correct me if I'm wrong but your original suggestion of changing : "if ((status & 0x10) == 0x10)" into "if ((status & 0x10) != 0x10)" Was translated in the driver into a change to: if ((status & 0x10) == 0x00)) which isn't exactly equivalent. > Maybe you could let us know a bit more what you're trying to do and > which setup you're using exactly (card device ID, subsystem ID, driver > version, format: PAL or NTSC? VBI or video grab? Maybe using overlay > in parallel?) > I'm using the tvtime directfb matrox crtc2 code (updated to work with the new output api tvtime is current using). Its possible I've done something stupid with the code but given that you mentioned the change conflicted with vendor specified behaviour and reversing the change had things work perfectly for me I'd say the driver is more likely at fault at the moment. I get the following in modprobe: saa7130/34: v4l2 driver version 0.2.8 loaded PCI: Found IRQ 9 for device 00:10.0 PCI: Sharing IRQ 9 with 00:09.0 saa7134[0]: found at 00:10.0, rev: 1, irq: 9, latency: 32, mmio: 0xdb000000 saa7134[0]: subsystem: 5168:0138, board: LifeView FlyVIDEO3000 [card=2,autodetected] i2c-dev.o: Registered 'saa7134[0]' as minor 3 tuner: chip found @ 0xc2 tuner: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) i2c-core.o: client [Philips PAL_BG (FI1216 and compa] registered to adapter [saa7134[0]](pos. 0). i2c-core.o: adapter saa7134[0] registered as adapter 3. saa7134[0]: i2c eeprom 00: 68 51 38 01 10 28 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: flyvideo: gpio is 0x39000 saa7134[0]: registered device video0 [v4l2] saa7134[0]: registered device vbi0 saa7134[0]: registered device radio0 Using PAL as suggested by the tuner autodetect. I'd be interested to hear if any other flyvideo 3000 owners have field order issues with the 0.2.7 and later saa7134 driver. Actually any saa7134 tvtime users feedback would be useful. -- Richard Jones <richard@xxxxxxxxxxxx>
