Date: Tue, 23 Jan 1996 12:58:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: james@miller.cs.uwm.edu (Jim Lowe) Cc: luigi@labinfo.iet.unipi.it, terry@lambert.org, 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: <199601231958.MAA18219@phaeton.artisoft.com> In-Reply-To: <199601231825.MAA23925@miller.cs.uwm.edu> from "Jim Lowe" at Jan 23, 96 12:25:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Unfortunately I think this would require non-trivial changes to the
> > > code in sysv_shm.c, and might possibly have some side effects.
> > >
> > > I am cross-posting this to hackers for advice.
> >
> > I would suggest adding an mmap() entry point for the device driver
> > and calling it when you request pages to be mmapped. The system
> > mmap() interface would not be changed, it would just act differently
> > for vnodes that were devices.
> >
> > This would work for mapping video memory by device generically as well
> > as frame capture buffers, etc..
>
> The device driver already has a mmap entry point. It allocates
> memory at boot up time (since you can't seem to grab that much
> wired down contiguous memory at run time -- for some reason).
>
> The video capture board DMAs its data into this preallocated
> memory. The user program uses the mmap system call to access
> this memory. Now, we want this memory to be shared by the
> Xserver with the Xshm utilities.
>
> How does one mark the driver/mmapped memory as shared memory
> with the current utilities? It isn't real obvious that one can
> actually do this without modifiying the shmat system call (or at
> least to me).
int fd;
caddr_t mapaddr;
if( ( fd = open( DEV_NAME, O_RDWR)) == -1) {
perror( "open");
exit( 1);
}
mapaddr = mmap( 0, /* map here, 0 = don't care*/
DEV_MEM_SIZE, /* device memory window*/
PROT_READ|PROT_WRITE, /* will be reading/writing*/
MAP_HASSEMAPHORE, /* (?) prevent caching*/
fd, /* fd for device*/
(off_t)0 /* full window*/
);
This above should work. If it doesn't, then the mmap() facility is
broken, either at the device driver level or elsewhere.
I may be misusing MAP_HASSEMAPHORE. I'd prefer an implied non-cached
mapping, shared, not copy-on-write. This should be true for any device
mapping and thus should not be a required flag to make it work.
I would also prefer the DEV_MEM_SIZE to be implicit to the driver,
and to use the offset (last argument) as a multiplex selector (for
instance, 0 for the first bank of display memory, 1 for the second, etc.
for multiple display cards on the driver... this is how the Sol
fiber optic boards worked in SCO for mapping multiple consoles and
doing direct video I/O from the standard kernel console driver for
several X stations on a single card).
For the ttyv0, ttyv1, etc., the memory ought to be the associated
screen memory for the console; that is, the memory in the backing
store for the screen for console switching, not the physical display
RAM itself.
The above should be true regardless of mode, but since the X server
is permitted to modify card registers promiscuously (ie: without telling
the console driver and in such a way that the console driver itself
can't put it back by itself), this must be broken for anything but
standard console video modes.
I believe this currently does not work on the console; instead, you must
map the physical address of screen memeory in a driver and go from /dev/mem
or however else from there.
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?199601231958.MAA18219>