Date: Mon, 29 Sep 1997 21:36:02 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Amancio Hasty <hasty@rah.star-gate.com> Cc: User Al Johnson <Al.Johnson@AJC.State.Net>, freebsd-multimedia@FreeBSD.ORG Subject: Re: fxtv Message-ID: <19970929213602.53357@ct.picker.com> In-Reply-To: <199709300048.RAA06881@rah.star-gate.com>; from Amancio Hasty on Mon, Sep 29, 1997 at 05:48:54PM -0700 References: <19970929191238.29355@ct.picker.com> <199709300048.RAA06881@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Amancio Hasty:
|>Randall Hopper:
|
|> Also, you'll see that when your video window is situated so X % 3 == 0,
|> the window looks OK, whereas with X % 3 == 1, your video will be
|> displayed with RGB mapped to BRG, and with X % 3 == 2, RGB -> GBR. All
|> that is changing from the app side is the start address in PCI memory,
|> but it somehow seems
|
|Interesting, are you trying to capture odd widths ?
No, Fxtv does ensure even widths. Reproduced these probs with the default
324x244 window that Fxtv 0.44 comes up with.
Experimenting some more, the RGB sync prob (quoted above) as well as the
black line artifact w/ half-n-half color prob I also mentioned appear to be
tied to the DMA transfer address.
In particular, its the modulo of the transfer address with 4 that's the
ticket:
addr % 4 == 0 - Looks good
addr % 4 == 1 - Vertical black line up center of window;
left side colors fine; right side is blueish
(RGB off-sync w/ framebuf right of center)
addr % 4 == 2 - Vertical black line up center of window;
left side blueish; right side greenish
addr % 4 == 3 - No vertical black line;
entire window greenish
To duplicate, uncomment the 2 printfs around tvcapture.c line 1490 and
run "fxtv -geometry +<x>+<y>" with some permutations of <x> and <y>.
Randall
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970929213602.53357>