Date: Tue, 23 Jan 1996 17:08:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: terry@lambert.org, james@miller.cs.uwm.edu, dufault@hda.com, hackers@FreeBSD.org, hasty@rah.star-gate.com, jkh@time.cdrom.com, multimedia@rah.star-gate.com Subject: Re: Amancio's tv program with capture! Message-ID: <199601240008.RAA18619@phaeton.artisoft.com> In-Reply-To: <199601232203.XAA08426@labinfo.iet.unipi.it> from "Luigi Rizzo" at Jan 23, 96 11:03:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> You are right that such a mechanism should be implemented by the
> server. Unfortunately it does not seem to be available, unless the
> often cited "DGA" (which I don't know) can help.
>
> We were simply trying to circumvent the lack of such a mechanism.
> We were looking at XShm calls to possibly save one or more copies
> in the way from the frame grabber to the frame buffer.
> That is, currently we have the following:
>
> 1. video input --> mmapped system memory
> (done by the DMA on the frame grabber; PCI-intensive)
> 2. system memory --> shared memory
> (done by the CPU with a bcopy; CPU intensive)
> 3. shared memory --> video memory
> (done with an XShmPutImage(); CPU & PCI intensive)
>
> Step 3. is possibly the most expensive (I don't know how many copies
> are involved). Step 2. could be saved if the two areas were on the same
> physical pages. Step 1. is PCI-bus intensive, but leaves the CPU free
> [not that it matters too much, given that at the end we just want to
> watch TV in an Xwindow!]
Step 2 is definitely the only one that can be avoided, unless your
capture card operates by using main video memory.
I think the problem is that you want to use an X paradigm for video
capture memory wiring, and it doesn't work.
You might be able to map the region and treat it as a pixmap, if it
were a linear frame buffer. You would have to mangle a pixmap header
onto the front of it.
You should be able to do this semi-transparently to X by mapping a 4k
file at some page offset, then mapping the linear memory from the
device immediately following that.
Then you point a struct * to the map region - sizeof(struct header),
and use it as if it were attached to the front of the "pixmap" from
the frame buffer. This would guarantee the necessary memory adjacency
for the "pixmap" to turn it into an "X pixmap" which is pending a
copy down to the card.
You could wrap this up as if it were a single interface, and return
the address of the page-end-offset header as a result of a call, but
I see little hope of jamming a real X interface on it *and* saving the
copy. You can do one or the other, but both would require all hardware
to be vaguely similar to make it work.
,------------------- Mapped 4k file
| ,-- Mapped video capture memory
,--^---.,-----------^----... ...--.
,------.,------.,------.,-... ...--.
| X|| || || |
`------'`------'`------'`-... ...--'
^ ^
| `---------------------------------.
| |
Pixmap header, negative offset from 4k adjacency boundry
I don't know how you'd deal with the Putimage/copy speed thing...
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601240008.RAA18619>