From owner-freebsd-hackers Wed Jan 24 18:51:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA15901 for hackers-outgoing; Wed, 24 Jan 1996 18:51:24 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA15801 for ; Wed, 24 Jan 1996 18:50:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA19933; Wed, 24 Jan 1996 18:47:30 -0800 To: Terry Lambert cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo), james@miller.cs.uwm.edu, dufault@hda.com, hackers@FreeBSD.org, hasty@rah.star-gate.com, multimedia@rah.star-gate.com Subject: Re: Amancio's tv program with capture! In-reply-to: Your message of "Tue, 23 Jan 1996 17:08:22 MST." <199601240008.RAA18619@phaeton.artisoft.com> Date: Wed, 24 Jan 1996 18:47:30 -0800 Message-ID: <19923.822538050@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > 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. Terry, with all due respect, I think you *still* don't understand the problem. The shared memory segment is NOT created by the server, not is any special formattting of the area reauired. There are extension calls for using the shared memory segment in a way that is understood by both server and client. I think you really should take a look at the code at this point since every message I've seen from you on this topic only indicates that you're getting further from understanding, not closer. Greetings from USENIX, BTW. I've talked to a number of your cronies from Novell. Quite amusing - they all have such interesting stories to tell! :-) Jordan > > 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.