Date: Sat, 27 Jan 1996 23:50:43 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Terry Lambert <terry@lambert.org>, 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! Message-ID: <199601280750.XAA00879@rah.star-gate.com> In-Reply-To: Your message of "Sat, 27 Jan 1996 23:10:31 PST." <28161.822813031@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> "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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601280750.XAA00879>