From owner-freebsd-hackers Sat Jan 27 23:55:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA00823 for hackers-outgoing; Sat, 27 Jan 1996 23:55:27 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA00818 for ; Sat, 27 Jan 1996 23:55:25 -0800 (PST) Received: from rah.star-gate.com (localhost [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id XAA00879; Sat, 27 Jan 1996 23:50:44 -0800 Message-Id: <199601280750.XAA00879@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "Jordan K. Hubbard" cc: Terry Lambert , luigi@labinfo.iet.unipi.it, james@miller.cs.uwm.edu, dufault@hda.com, hackers@freebsd.org, multimedia@rah.star-gate.com Subject: Re: Amancio's tv program with capture! In-reply-to: Your message of "Sat, 27 Jan 1996 23:10:31 PST." <28161.822813031@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Jan 1996 23:50:43 -0800 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> "Jordan K. Hubbard" said: > > 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): Goodness gracious at least a hint at code 8) > > fbmem = mmap(.. blah ..) > shmid = shmget(.. some memory chunk size and allocation info ..) > ximage->data = shmat(shmid, 0, 0); > bcopy(fbmem, ximage->data, ..size..) > The direction which I am thinking of taking is to wired the graphic card's frame buffer to the matrox meteor driver . This way the meteor can dump video data with no software intervention whatsover and if the graphic card is capable we should be able to see 640x480*4 at 30fps. My rationale for doing this is just speed, speed, and speed and the pathetic memory bandwith that we have in the Pentium. The safest way of doing this without crashing some S3 engines is to use the DGA extensions to grab the frame buffer this does three things: 1. Disables the cursor --- which on some S3 chipsets is known to crash the graphic engine if the linear buffer is enabled. 2. Typically, the linear buffer is only accessible during access to the frame buffer and all other times is disabled. However, with the DGA extensions -- I would imagine that the linear buffer most remain enabled till one releases the frame buffer via the DGA extensions. 3. I can spot graphic cards which don't support a linear buffer or don't have the linear buffer mmap and in such cases just exit out of tv or resort to the shared memory method. The changes required to support wiring the graphic card's buffer to the meteor driver are minimal. The *additional* information needed by the meteor driver is: 1. start of the frame buffer's physical memory 2. stride or number of words to skip per line. The Philips has a register which specifies how may pixels to add before displaying the next line. So that we can in theory do this: ..................................... ..................................... .............**************.......... .............**************.......... .............**************.......... .............**************.......... .............**************.......... .............**************.......... ..................................... ..................................... The "*" denotes the video display output from the matrox meteor. With DGA we should be able to figured out very easily the number for the stride parameter. Wherever we mmap the physical memory of the frame buffer in the kernel it can fill out a simple data structure which contains the physical location of the frame buffer and its size. Jim suggested the following data structure: #ifndef METEOR_NVGA #define METEOR_NVGA 1 #endif struct vga_frame_info { unsigned char *frame_buffer_addr; unsigned int size; } vga_frame_info[METEOR_NVGA] = {(u_char *)0, 0}; Now with something like the video extensions is conceivable with little pain to dump the video stream to the off display region and then use proper X semantics to display the frame. Usually internal blts in graphic engine have tons of bandwith. Additionally, if we are on the server side we could also managed the cache region in the off display memory segment on the graphic card. *First* phase at high speed video just raw dump on the screen. *Second phase port the xvideo extensions to XFree86 and make necessary changes to the X server. Now, for the religious X cult fans if they don't like this approach they can always resort to a shared buffer access at the cost of lower performance. Any questions ? 8) Enjoy, Amancio