[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-video
Subject:    Re: [video4linux] Few API Questions / bt848 related questions
From:       Richard Guenther <zxmpm11 () student ! uni-tuebingen ! de>
Date:       1998-07-25 9:50:49
[Download RAW message or body]

On Thu, 23 Jul 1998, Ralph Metzler wrote:

> Richard Guenther writes:
>  > I have to do real time image processing with input from two
>  > cameras. There are a few related questions to this topic
>  > 
[SNIP]

>  > - How can I grab into a SYSV shm area?? With mmapped capture
>  >   this is not possible (?) Perhaps we should allow a 'hint'
>  >   to the capture ioctl to set the buffer address from userspace?
>  >   How can I get the actual buffer size needed for the capture?
>  >   I see, that the size is (now) always the same, regardless of
>  >   the actual size of the frame to be grabbed!?
> 
> Previous versions of bttv where grabbing into locked user memory.
> Since it was hard (impossible) to lock memory from a kernel module this relied
> on the user program to lock and also provide actually existing pages by 
> faulting them (both is not such a good idea to be done by a user program ...).
> You could of course adapt this old code to use SYSV shm areas.
> Alan mentioned sometime that there are plans for general support of DMA
> into user memory for 2.2.x?!

Couldn't we just support opening /dev/videoX more than one times? I.e.
one time R/W and several times RO, so that every task can mmap the
grab-buffer? (Hmmm - we would have to add ioctls to allocate a
specific buffer (size, mode - i.e. shareable or not) and a ioctl
to mmap this buffer)

Richard.

--
Richard Guenther <richard.guenther@student.uni-tuebingen.de>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/

------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

[prev in list] [next in list] [prev in thread] [next in thread]