From owner-freebsd-hackers Tue Jan 23 14:05:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA22078 for hackers-outgoing; Tue, 23 Jan 1996 14:05:45 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA22068 for ; Tue, 23 Jan 1996 14:05:31 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id XAA08426; Tue, 23 Jan 1996 23:03:28 +0100 From: Luigi Rizzo Message-Id: <199601232203.XAA08426@labinfo.iet.unipi.it> Subject: Re: Amancio's tv program with capture! To: terry@lambert.org (Terry Lambert) Date: Tue, 23 Jan 1996 23:03:28 +0100 (MET) Cc: james@miller.cs.uwm.edu, terry@lambert.org, dufault@hda.com, hackers@FreeBSD.org, hasty@rah.star-gate.com, jkh@time.cdrom.com, multimedia@rah.star-gate.com In-Reply-To: <199601232131.OAA18383@phaeton.artisoft.com> from "Terry Lambert" at Jan 23, 96 02:30:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org Precedence: bulk > What is it you want, and what does any of this have to do with Xshm? > > If anything, an X implemented on such a device layering and mapping > facility would have an API mechanism to get at the memory area instead > of using IPC to a DDX facility... that is, we are talking about mapping > in the server, not in the client. For client mapping, the standard > API would have to be used in situ and applied against the driver rather > than a region exported by the server. 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!] We (that is, I, Jim, Amancio, Jordan) don't know how to save Step 2 it or if this is possible at all. Additionally, I don't believe I have been able to state the problem clearly :) However, and somewhat surprisingly, XShm...() provides a nicer output because the whole window seems to be repainted without interruptions (while the conventional XPutImage quite often blocks at some point while redrawing the image) Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ====================================================================