From owner-freebsd-hackers  Sun Jan 28 13:28:07 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id NAA02148
          for hackers-outgoing; Sun, 28 Jan 1996 13:28:07 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA02127
          for <hackers@freebsd.org>; Sun, 28 Jan 1996 13:28:01 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA01493; Sun, 28 Jan 1996 14:24:19 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199601282124.OAA01493@phaeton.artisoft.com>
Subject: Re: Amancio's tv program with capture!
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Sun, 28 Jan 1996 14:24:19 -0700 (MST)
Cc: terry@lambert.org, luigi@labinfo.iet.unipi.it, james@miller.cs.uwm.edu,
        dufault@hda.com, hackers@freebsd.org, hasty@rah.star-gate.com,
        multimedia@rah.star-gate.com
In-Reply-To: <28161.822813031@time.cdrom.com> from "Jordan K. Hubbard" at Jan 27, 96 11:10:31 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
Precedence: bulk

> > But that object can't be exported as a shared memory region of a type
> > the server can understand, since the layout won't match that of the
> > Xshm protocol.
> 
> Maybe I really am missing the boat, but I'm still having a hard time
> understanding that if (and forgive me if I resort to pseudo- code -
> it's been a long week):
> 
> 	fbmem = mmap(.. blah ..)
> 	shmid = shmget(.. some memory chunk size and allocation info ..)
> 	ximage->data = shmat(shmid, 0, 0);
> 	bcopy(fbmem, ximage->data, ..size..)
> 
> Works *just fine*, e.g. the ximage data is happy to point at the
> memory allocated by shmget and I can bcopy straight into this region
> from the frame buffer, sans any special offsets or conversion, then
> how can:
> 
> 	fbmem = mmap(.. blah ..)
> 	shmid = shmget(.. no memory please, just an entry ..)
> 	ximage->data = shmat(shmid, fbmem, 0);
> 
> work when shmget() doesn't support any such semantics?  It seems like
> that would be the minimum level of hacking required to even give this
> a ghost's chance of working.

You can support those semantics for mmap using a pseudo device to
actually establish "just an entry" given the normal mmap argument
space.

This is still a kludge because you still have two sets of memory that
can't be reconciled: the physical memory on the video capture card, and
the physical memory on the display card.  You *can't* map them to the
same location.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.