Date: Tue, 23 Jan 1996 16:52:11 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Cc: terry@lambert.org, james@miller.cs.uwm.edu, dufault@hda.com, hackers@FreeBSD.org, jkh@time.cdrom.com, luigi@labinfo.iet.unipi.it, multimedia@rah.star-gate.com Subject: Re: Amancio's tv program with capture! Message-ID: <199601232352.QAA18599@phaeton.artisoft.com> In-Reply-To: <199601232154.NAA02080@rah.star-gate.com> from "Amancio Hasty Jr." at Jan 23, 96 01:54:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > What is it you want, and what does any of this have to do with Xshm? > > Well okay, let me try to clarify the issue. > > tv mmaps a region to be used by the matrox meteor to dump the > data to: > yuv_data = (uint8 *)mmap((caddr_t)0, frame_size, > PROT_READ,0, video, (off_t)0); > --- > > The Xshm memory bits comes into play like this: > > ximage = XShmCreateImage (display, fc_visual, depth, ZPixmap, > NULL, &shminfo, vid_stream->mb_width, > vid_stream->mb_height); > shminfo.shmid = shmget (IPC_PRIVATE, > ximage->bytes_per_line * ximage->height, > IPC_CREAT | 0777); > shminfo.shmaddr = ximage->data = shmat (shminfo.shmid, 0, 0); > shminfo.readOnly = True; > XShmAttach (display, &shminfo); > > --- > What we want is to dump the data that the meteor captures directly > into the card's frame buffer. > > If you don't understand this then lets take this privately between Jim, you > and I. I understand. You want to use theshared memory region as if it had been created by an X server. >From my understanding of the MIT shared memory extensions, this might only be possible if you add some additional fields and values as if you were an X server. My impression is that if the device memory mapped were from the memory of a linear framebuffer, then it could be used for the data pointer for the image without modification (you would have to fake a header for it, but otherwise it should be treatable as a pixmap the size of the memory area of a depth equal to the card settings, but without the header. I think the misconception here comes from expecting a device to have the same memory layout in the mapped region as if it were on the user side of the DDX interface already. I believe this would only be true of specific devices, but not true in the general sense. My inclination would be to tell you to avoid mapping it into the Xshm interface unless you map it through an X server (which the Xshm currently requires) that happens to use the mapping API in a (potentially) device dependent fashion. Which is to say you must consider it as part of the DDX->frame buffer interface, if you consider it at all. Without a lot of dancing to export a mapped region as a shared memory segment (which is what I think you might really want instead), you are going to have a hard time making the BSD (mmap) and SVR4 (shm) systems talk nicely to each other, IMO. 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?199601232352.QAA18599>