Anyone working on V4L2 for BSD?

[Julian Elischer]

I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)

For compatibility we'd probably want to keep all the V4L prefixes etc.

Is anyone else playing with this?

I remember someone said they had implemented
part of the interface for some specific device recently.


Julian

[Christian Gusenbauer]

Hi Julian!

I played a bit with it 3 years ago. I managed to get the radio part working,
but then I had no time left to do the rest :-(. If you want, I can send you
my sources.

Ciao,
Christian.

Post by Julian Elischer
I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)
For compatibility we'd probably want to keep all the V4L prefixes etc.
Is anyone else playing with this?
I remember someone said they had implemented
part of the interface for some specific device recently.
Julian
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia
To unsubscribe, send any mail to

[Lluis López]

Post by Julian Elischer
I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)
For compatibility we'd probably want to keep all the V4L prefixes etc.
Is anyone else playing with this?
I remember someone said they had implemented
part of the interface for some specific device recently.

http://www.h7.dion.ne.jp/~teragen/
This is another driver for cxm cards by Tomomi Suzuki. It suports all
the encoder interface, have a gtk2 grafic controler and v4l2
compatibility, but only works with YUAN or IO-DATA cards. I'm porting
this driver for pvr250 (and pvr350 in next future), but I will need
more dmesg and pciconf -lv of other cards for best support.

Luis López Solé

[Jacob Meuser]

Post by Julian Elischer
I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)

I can forsee at least one big obstacle in the bktr driver. it is
necessary to call TVTUNER_SETTYPE before setting the tuner, even if
you use TVTUNER_SETFREQ, which is quite different than V4L2.

there are several bugs lurking in bktr. for example, why are the
U saturation and V saturation ranges different? according to the
datasheets they should be the same. also notice that on startup
bktr reports a U saturation above the supposed limit!

I'd much rather see the problems fixed than a shim added to it.
how about working about multiple frame buffers? that's probably need
for many V4L2 programs. IMO, it would be better (maybe even easier)
to rewrite bktr with a V4L2 interface than to try to add V4L2 to it.

but, IMO, the best thing would be to fix bktr and document it better.

some bktr programs -> http://www.jakemsr.com/bsdav/bsdav-1.0.tar.gz

[Julian Elischer]

Post by Jacob Meuser

Post by Julian Elischer
I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)

I can forsee at least one big obstacle in the bktr driver. it is
necessary to call TVTUNER_SETTYPE before setting the tuner, even if
you use TVTUNER_SETFREQ, which is quite different than V4L2.
there are several bugs lurking in bktr. for example, why are the
U saturation and V saturation ranges different? according to the
datasheets they should be the same. also notice that on startup
bktr reports a U saturation above the supposed limit!

If you supply fixes.. and others can test them, I can commit them..
I don't have a bktr card.

Post by Jacob Meuser
I'd much rather see the problems fixed than a shim added to it.
how about working about multiple frame buffers? that's probably need
for many V4L2 programs. IMO, it would be better (maybe even easier)
to rewrite bktr with a V4L2 interface than to try to add V4L2 to it.

I wasn't planning on either, but rather making a v4l2 framework to allow
drivers and utilities to hook to each other.. whether the bktr driver
gets rewritten
or shimmed is an orthogonal question :-)

Post by Jacob Meuser
but, IMO, the best thing would be to fix bktr and document it better.

anyone who wants to fix or rewrite it is quite welcome to do so..
if it's an improvement, it'll get committed..

I'm interested in webcams at the moment. I want to see if it's possible
to make it easier for
people to port such things as gnome-meeting (higher rev than the port)
so that we can get
some real videoconferencing in freeBSD.

Post by Jacob Meuser
some bktr programs -> http://www.jakemsr.com/bsdav/bsdav-1.0.tar.gz

[Christian Gusenbauer]

Hi!

Post by Julian Elischer

Post by Jacob Meuser
I'd much rather see the problems fixed than a shim added to it.
how about working about multiple frame buffers? that's probably need
for many V4L2 programs. IMO, it would be better (maybe even easier)
to rewrite bktr with a V4L2 interface than to try to add V4L2 to it.

I wasn't planning on either, but rather making a v4l2 framework to allow
drivers and utilities to hook to each other.. whether the bktr driver
gets rewritten
or shimmed is an orthogonal question :-)

Well, that's exactly what I wrote some years ago. There's on one hand the v4l2
framework and on the other hand there's a driver (in my case, it's a bktr
one) which registers itself at the v4l2 framework. Then, the latter creates
the device nodes and the applications use these nodes to get in contact with
the driver. Julian, I think that's what you are looking for, isn't it?

Ciao,
Christian.

[Julian Elischer]

Post by Christian Gusenbauer
Hi!

Post by Julian Elischer

Post by Jacob Meuser
I'd much rather see the problems fixed than a shim added to it.
how about working about multiple frame buffers? that's probably need
for many V4L2 programs. IMO, it would be better (maybe even easier)
to rewrite bktr with a V4L2 interface than to try to add V4L2 to it.

I wasn't planning on either, but rather making a v4l2 framework to allow
drivers and utilities to hook to each other.. whether the bktr driver
gets rewritten
or shimmed is an orthogonal question :-)

Well, that's exactly what I wrote some years ago. There's on one hand the v4l2
framework and on the other hand there's a driver (in my case, it's a bktr
one) which registers itself at the v4l2 framework. Then, the latter creates
the device nodes and the applications use these nodes to get in contact with
the driver. Julian, I think that's what you are looking for, isn't it?

yes
I'd like to look at what you got done..
I'm also trying to contact the Linux developers about the ability to use
their .h file directly.
having a V4L interface available will make such things as gnomemeeting
and SANE
porting a LOT easier.

Post by Christian Gusenbauer
Ciao,
Christian.

[Christian Gusenbauer]

Hi Julian!

I'll send you the sources.

Ciao,
Christian.

Post by Julian Elischer

Post by Christian Gusenbauer
Hi!

Post by Julian Elischer

Post by Jacob Meuser
I'd much rather see the problems fixed than a shim added to it.
how about working about multiple frame buffers? that's probably need
for many V4L2 programs. IMO, it would be better (maybe even easier)
to rewrite bktr with a V4L2 interface than to try to add V4L2 to it.

I wasn't planning on either, but rather making a v4l2 framework to allow
drivers and utilities to hook to each other.. whether the bktr driver
gets rewritten
or shimmed is an orthogonal question :-)

Well, that's exactly what I wrote some years ago. There's on one hand the
v4l2 framework and on the other hand there's a driver (in my case, it's a
bktr one) which registers itself at the v4l2 framework. Then, the latter
creates the device nodes and the applications use these nodes to get in
contact with the driver. Julian, I think that's what you are looking for,
isn't it?

yes
I'd like to look at what you got done..
I'm also trying to contact the Linux developers about the ability to use
their .h file directly.
having a V4L interface available will make such things as gnomemeeting
and SANE
porting a LOT easier.

Post by Christian Gusenbauer
Ciao,
Christian.

[John Wehle]

_______________________________________________
freebsd-***@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia
To unsubscribe, send any mail to "freebsd-multimedia-***@freebsd.org"

[Julian Elischer]

Post by Julian Elischer
Is anyone else playing with this?
I remember someone said they had implemented
part of the interface for some specific device recently.

my cxm driver for the Hauppauge PVR-250 / PVR-350.
I've been lightly debating what to do about adding support ...
if there was an official FreeBSD framework, then I'd be happy to
update the cxm driver to interfaced with it.

There are two interfaces that we can consider..
The X11R6 Xvideo interface (about which I know very little)
and V4L(2).
There is however a shim that allows Xvideo to talk to L4V so I think we
should look
at making hte devices L4V compliant. I just got permission from the
original author of the L4V
interface to copy the include file verbatim should we like.

-- John
-------------------------------------------------------------------------
| John Wehle | Fax: [phone] | |
-------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-current

[Alexander Leidinger]

Post by Julian Elischer
I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)
For compatibility we'd probably want to keep all the V4L prefixes etc.
Is anyone else playing with this?

There was a discussion about something like this a while ago... a, I see you
participated in it too:
http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html
http://people.freebsd.org/~jmg/videobsd.html

Bye,
Alexander.

[Jacobo Arvelo "UNIX4ALL"]

Post by Alexander Leidinger

Post by Julian Elischer
I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)
For compatibility we'd probably want to keep all the V4L prefixes etc.
Is anyone else playing with this?

There was a discussion about something like this a while ago... a, I see you
http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html
http://people.freebsd.org/~jmg/videobsd.html
Bye,
Alexander.
--
Elves on strike (Why do they call EMAG Elf Magic?)
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia

Hi all:

I think that a framework to video devices such as V4L but for FreeBSD
is a must to have feature to the spreading of FreeBSD in the Desktop
market, the only thing on my computer that I can´t managed to work in
FreeBSD is my webcam :(.

Sorry for my bad english.

greetings,

[John-Mark Gurney]

Post by Alexander Leidinger

Post by Julian Elischer
I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)
For compatibility we'd probably want to keep all the V4L prefixes etc.
Is anyone else playing with this?

There was a discussion about something like this a while ago... a, I see you
http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html
http://people.freebsd.org/~jmg/videobsd.html

Yes, I did... and unless V4L2 managed to change a lot.. It's API is
still years behind what we should have... The reason I haven't said
anything is that I didn't want to attempt to derail any work that someone
might be doing.. Yes, V4L2 is not a very good api, but as others have
pointed out, it makes portability easier... Plus, I haven't spent any
time on VideoBSD recently, since I've gotten sidetracked by other
projects... (Though if I can get ATI to give me specs for their HDTV
PCI card, I might spend some more time on it...)

So, if you just want Linux compatiblity, go for it... If you want a
real usable video API, then send me comments and look at the VideoBSD
stuff I have done...

[Julian Elischer]

Post by John-Mark Gurney

Post by Alexander Leidinger

Post by Julian Elischer
I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)
For compatibility we'd probably want to keep all the V4L prefixes etc.
Is anyone else playing with this?

There was a discussion about something like this a while ago... a, I see you
http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html
http://people.freebsd.org/~jmg/videobsd.html

Yes, I did... and unless V4L2 managed to change a lot.. It's API is
still years behind what we should have... The reason I haven't said
anything is that I didn't want to attempt to derail any work that someone
might be doing.. Yes, V4L2 is not a very good api, but as others have
pointed out, it makes portability easier... Plus, I haven't spent any
time on VideoBSD recently, since I've gotten sidetracked by other
projects... (Though if I can get ATI to give me specs for their HDTV
PCI card, I might spend some more time on it...)

My sugestion is that we make V4L2 an alternative interface to a videoBSD
framework.
Think "netgraph for video" with a V4L2 frontend for apps and a v4l2
backend for drivers.
The difference is that the framework would interpret all the ioctls etc
instead of the
drivers themselves. The drivers MAY attach using a V4L2 interface, but
the requersts they
get MAY or MAY NOT have come from the clients. In the middle we have
support for
modules that do simple format conversion, resynching, snipping, and the
ability to
pass the stream out to a userlandeditor and get it back again, for
really compilcated
editing.

Some requests fromt the clients may be passed through to the drivers.
Some may not.

Post by John-Mark Gurney
So, if you just want Linux compatiblity, go for it... If you want a
real usable video API, then send me comments and look at the VideoBSD
stuff I have done...

[Harti Brandt]

On Wed, 13 Apr 2005, Julian Elischer wrote:

JE>John-Mark Gurney wrote:
JE>
JE>> Alexander Leidinger wrote this message on Wed, Apr 13, 2005 at 14:31 +0200:
JE>>
JE>> > Julian Elischer <***@elischer.org> wrote:
JE>> >
JE>> >
JE>> > > I'm considerring it.. It looks quite doable. (assuming we can get
JE>> > > compatible include files
JE>> > > without copyright problems.)
JE>> > >
JE>> > > For compatibility we'd probably want to keep all the V4L prefixes etc.
JE>> > >
JE>> > > Is anyone else playing with this?
JE>> > >
JE>> > There was a discussion about something like this a while ago... a, I see
JE>> > you
JE>> > participated in it too:
JE>> > http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html
JE>> > http://people.freebsd.org/~jmg/videobsd.html
JE>> >
JE>>
JE>> Yes, I did... and unless V4L2 managed to change a lot.. It's API is
JE>> still years behind what we should have... The reason I haven't said
JE>> anything is that I didn't want to attempt to derail any work that someone
JE>> might be doing.. Yes, V4L2 is not a very good api, but as others have
JE>> pointed out, it makes portability easier... Plus, I haven't spent any
JE>> time on VideoBSD recently, since I've gotten sidetracked by other
JE>> projects... (Though if I can get ATI to give me specs for their HDTV
JE>> PCI card, I might spend some more time on it...)
JE>>
JE>
JE>My sugestion is that we make V4L2 an alternative interface to a videoBSD
JE>framework.
JE>Think "netgraph for video" with a V4L2 frontend for apps and a v4l2 backend
JE>for drivers.

If you take this without the quotes this is something I wanted to do for
years (started even once to try it on streams under Solaris). There is
often no need to funnel all the video and audio traffic through user space
just to pull it out of one device and put it into another one. This
requires some thought though for memory mapped devices.

harti

JE>The difference is that the framework would interpret all the ioctls etc
JE>instead of the drivers themselves. The drivers MAY attach using a V4L2
JE>interface, but the requersts they get MAY or MAY NOT have come from the
JE>clients. In the middle we have support for modules that do simple
JE>format conversion, resynching, snipping, and the ability to pass the
JE>stream out to a userlandeditor and get it back again, for really
JE>compilcated editing. Some requests fromt the clients may be passed
JE>through to the drivers. Some may not.
JE>
JE>
JE>> So, if you just want Linux compatiblity, go for it... If you want a
JE>> real usable video API, then send me comments and look at the VideoBSD
JE>> stuff I have done...
JE>>
JE>>
JE>_______________________________________________
JE>freebsd-***@freebsd.org mailing list
JE>http://lists.freebsd.org/mailman/listinfo/freebsd-current
JE>To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
JE>
JE>
JE>

[Kevin Oberman]

Date: Wed, 13 Apr 2005 14:31:26 +0200

Post by Julian Elischer
I'm considerring it.. It looks quite doable. (assuming we can get
compatible include files
without copyright problems.)
For compatibility we'd probably want to keep all the V4L prefixes etc.
Is anyone else playing with this?

There was a discussion about something like this a while ago... a, I see you
http://lists.freebsd.org/pipermail/freebsd-multimedia/2003-July/000328.html
http://people.freebsd.org/~jmg/videobsd.html

This is something I would love to see. FreeBSD being limited to various
forms of Brooktree video chips is a serious limitation in this day and
age. I routinely have to tell people who want to use our H.323
conferencing system from a laptop that they are OOL. :-( And even
desktop users are annoyed that they can't use their (already purchased)
USB cameras and that they have to get a camera with video output and a
WinTV card.

Of course, I am still fighting a battle with getting recent GnomeMeeting
to work on V5, but I do make a bit of progress on this from time to time
when I have a chance to work on it.