From owner-freebsd-hackers Tue Jan 23 12:10:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA12770 for hackers-outgoing; Tue, 23 Jan 1996 12:10:13 -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 MAA12763 for ; Tue, 23 Jan 1996 12:10:08 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA18219; Tue, 23 Jan 1996 12:58:02 -0700 From: Terry Lambert Message-Id: <199601231958.MAA18219@phaeton.artisoft.com> Subject: Re: Amancio's tv program with capture! To: james@miller.cs.uwm.edu (Jim Lowe) Date: Tue, 23 Jan 1996 12:58:02 -0700 (MST) 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 In-Reply-To: <199601231825.MAA23925@miller.cs.uwm.edu> from "Jim Lowe" at Jan 23, 96 12:25: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 > > > 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.