Date: Wed, 18 Apr 2007 22:40:09 +0200 From: Danny Pansters <danny@ricin.com> To: freebsd-questions@freebsd.org Subject: Re: mmap on freebsd vs linux Message-ID: <200704182240.09184.danny@ricin.com> In-Reply-To: <c39ec84c0704180905od39236ag5ec1091ec8f1a15@mail.gmail.com> References: <c39ec84c0704180905od39236ag5ec1091ec8f1a15@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm not really an expert on this but here goes... On Wednesday 18 April 2007 18:05:44 usleepless@gmail.com wrote: > Hi All, > > i am looking into implementing a piece of the V4L interface. this > involves mmap'ing from userspace into kernelspace. > > in mplayer, this is what is called: > > tvi_v4l2.c: > " > priv->map[i].addr = mmap (0, priv->map[i].buf.length, PROT_READ | > PROT_WRITE, MAP_SHARED, > priv->video_fd,priv->map[i].buf.m.offset); > " > > the file descriptor parameter is the file descriptor of the opened > capture device. the offset parameter should be filled in by the opened > device. A device won't fill in anything. A driver must. > does mmap work on freebsd as it works on linux? ie: can i mmap any > device? are there constraints on the device which should be met? You can mmap anything, but only if you get a (frame-) buffer of known size will it be useful to actually do something with it. The mplayer code probably takes the offset from what it knows about capture size (which for PAL/NTSC is known if also the YUV output type is known). You also need some signalling to know when to read the (new) buffer data again. I'd also advise to cast the address to caddr_t and the offset to off_t types. Will probably help compiling on 64 bits archs. And using both PROT_READ and PROT_WRITE seems non-sensical. You only want to read the buffer not (directly) write to it, unless perhaps if it contains more than just the framedata. That would seem bad design to me though, if you have to write to the same buffer that also contains data that you absolutely dont want to overwrite. I'm not familiar with v4l but simple and working mmap examples for FreeBSD with bktr and for saa are here: http://freebsd.ricin.com/kbtv/kbtv-1.2.4/bt848/bt848.c and http://freebsd.ricin.com/kbtv/kbtv-1.2.4/saa/saa.c Scroll down to Framebuffer. The buffer size is determined by the frame pixel size and by which YUV type is being used. The latter determines how much data is used on average per pixel, so you can calculate the datasize. See how bktr has offset 0 while saa has offset SAA_MMAP_T0_OFFSET. Both are what they are because of how their drivers are organized. See mmap(2) for the nitty-gritty on mmap. In general: if it segfaults or spontaneously reboots you likely made a mistake with the buffer size or offset :) HTH, Dan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704182240.09184.danny>