v4l device in userspace

v4l device in userspace

[Salvatore Sanfilippo]

Hello, I'm trying to implement a v4l device driver
for symbian based smart phones. In theory
it is very simple:

I've a little program running in the phone, capturing
images from the camera and sending it to the
linux box via bluetooth.

In the linux box side, I've a deamon capturing this
images (via a bluetooth SP channel), and....
I've to pass the images to a fake v4l device
driver that actually gets the images form userspace.

Basically I've to pass by the kernel just for
the interface, and not to do real kernel-side work
(like to access to the some kind of hardware).

So I've some questions ( thanks in advance
for any reply).

1) What's the best way to pass relatively
high-band data between the v4l fake driver
and userspace? A char device will do the
work? ioctl?

2) What about some way to handle ioctl
directly from userspace? Given this support
I may implement the whole code in userspace.
And I guess there are a lot of other real world
problems that can be handled in userspace
given the ability to handle ioctl from there.

If you think 2) is reasonable I may actually
implement some simple form of generic
char driver that just allows userspace
programs to handle read/write/ioctl
opreations, and then use this to fix
my real issue.

Thank you very much for the help,
and sorry if there is something conceptually
wrong in my questions.

Regards,
Salvatore

P.S. please take me in CC as I'm not subscribed
to the linux kernel mailing list.

-- 
Salvatore 'antirez' Sanfilippo
We're programmers. Programmers are, in their hearts, architects -- Joel Spolsky
http://www.invece.org

v4l device in userspace

[Marcus Metzler]

>>>>> "Salvatore" == Salvatore Sanfilippo <antirez@gmail.com> writes:

    Salvatore> Hello, I'm trying to implement a v4l device driver for
    Salvatore> symbian based smart phones. In theory it is very
    Salvatore> simple:

    Salvatore> I've a little program running in the phone, capturing
    Salvatore> images from the camera and sending it to the linux box
    Salvatore> via bluetooth.

    Salvatore> In the linux box side, I've a deamon capturing this
    Salvatore> images (via a bluetooth SP channel), and....  I've to
    Salvatore> pass the images to a fake v4l device driver that
    Salvatore> actually gets the images form userspace.

    Salvatore> Basically I've to pass by the kernel just for the
    Salvatore> interface, and not to do real kernel-side work (like to
    Salvatore> access to the some kind of hardware).

    Salvatore> So I've some questions ( thanks in advance for any
    Salvatore> reply).

    Salvatore> 1) What's the best way to pass relatively high-band
    Salvatore> data between the v4l fake driver and userspace? A char
    Salvatore> device will do the work? ioctl?

    Salvatore> 2) What about some way to handle ioctl directly from
    Salvatore> userspace? Given this support I may implement the whole
    Salvatore> code in userspace.  And I guess there are a lot of
    Salvatore> other real world problems that can be handled in
    Salvatore> userspace given the ability to handle ioctl from there.

    Salvatore> If you think 2) is reasonable I may actually implement
    Salvatore> some simple form of generic char driver that just
    Salvatore> allows userspace programs to handle read/write/ioctl
    Salvatore> opreations, and then use this to fix my real issue.

    Salvatore> Thank you very much for the help, and sorry if there is
    Salvatore> something conceptually wrong in my questions.

Sounds like you should take a look at the v4l loopback device
(http://www.lavrsen.dk/twiki/bin/view/Motion/VideoFourLinuxLoopbackDevice).
Otherwise it may be better to ask the question on the v4l mailing list
(https://listman.redhat.com/mailman/listinfo/video4linux-list).

Anyway, since you already capture the video, why do you have to pipe
it through a v4l device? 

Marcus

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/
 |>>>             Quis custodiet ipsos custodes                 <<<|

Re: v4l device in userspace

[Salvatore Sanfilippo]

On 6/16/06, Marcus Metzler <mocm@mocm.de> wrote:

> Sounds like you should take a look at the v4l loopback device

Thanks this may contain useful code indeed.

> Anyway, since you already capture the video, why do you have to pipe
> it through a v4l device?

In order to make every application using the v4l API
working with the phone cam without modifications.

Thanks,
Salvatore

-- 
Salvatore 'antirez' Sanfilippo
We're programmers. Programmers are, in their hearts, architects -- Joel Spolsky
http://www.invece.org

Re: v4l device in userspace

[Michael Krufky]

Salvatore Sanfilippo wrote:
> Hello, I'm trying to implement a v4l device driver
> for symbian based smart phones. In theory
> it is very simple:
>
> I've a little program running in the phone, capturing
> images from the camera and sending it to the
> linux box via bluetooth.
>
> In the linux box side, I've a deamon capturing this
> images (via a bluetooth SP channel), and....
> I've to pass the images to a fake v4l device
> driver that actually gets the images form userspace.
>
> Basically I've to pass by the kernel just for
> the interface, and not to do real kernel-side work
> (like to access to the some kind of hardware).
>
> So I've some questions ( thanks in advance
> for any reply).
>
> 1) What's the best way to pass relatively
> high-band data between the v4l fake driver
> and userspace? A char device will do the
> work? ioctl?
>
> 2) What about some way to handle ioctl
> directly from userspace? Given this support
> I may implement the whole code in userspace.
> And I guess there are a lot of other real world
> problems that can be handled in userspace
> given the ability to handle ioctl from there.
>
> If you think 2) is reasonable I may actually
> implement some simple form of generic
> char driver that just allows userspace
> programs to handle read/write/ioctl
> opreations, and then use this to fix
> my real issue.
>
> Thank you very much for the help,
> and sorry if there is something conceptually
> wrong in my questions.
>
> Regards,
> Salvatore
>
> P.S. please take me in CC as I'm not subscribed
> to the linux kernel mailing list.
>
I recommend resubmitting this question to a mailing list that actually 
focuses on this topic:

video4linux-list@redhat.com

However, I highly recommend that you subscribe before you post, as the 
redhat server adds a REPLY-TO header to the video4linux list emails, and 
has been known to drop cc's:

http://www.redhat.com/mailman/listinfo/video4linux-list

See you there!

-Michael Krufky

-- 
Michael Krufky

Re: v4l device in userspace

[Pavel Machek]

Hi!

> I've a little program running in the phone, capturing
> images from the camera and sending it to the
> linux box via bluetooth.

Nice!

> Basically I've to pass by the kernel just for
> the interface, and not to do real kernel-side work
> (like to access to the some kind of hardware).
> 
> So I've some questions ( thanks in advance
> for any reply).
> 
> 1) What's the best way to pass relatively
> high-band data between the v4l fake driver
> and userspace? A char device will do the
> work? ioctl?
> 
> 2) What about some way to handle ioctl
> directly from userspace? Given this support
> I may implement the whole code in userspace.
> And I guess there are a lot of other real world
> problems that can be handled in userspace
> given the ability to handle ioctl from there.
> 
> If you think 2) is reasonable I may actually
> implement some simple form of generic
> char driver that just allows userspace
> programs to handle read/write/ioctl
> opreations, and then use this to fix
> my real issue.

You probably want to do something v4l specigic... but generic userspace driver
 able to do read/write/ioctl would be very nice. Lots of devices these days are on usb, and that can be done from userspace, for example.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms