Technology and Trends
 Video for Linux Mailing List Archives
  
List:       linux-video
Subject:    [video4linux] v4l api comments / questions
From:       Gerd Knorr <kraxel () goldbach ! in-berlin ! de>
Date:       1998-11-15 16:11:36


  Hi !

Came across these problems while reading the specs, the header file and
hacking xawtv...

 * v4l2_framebuffer.base is a array if tree values.  What this is good
   for, especially the second and third?
 * v4l2_window has a "count" field, v4l2_clip has a "next" pointer.  How
   this is supported to work?  As array (then we don't need the next
   pointer) or as linked list (I would kill the count field then and
   define a NULL pointer as end of the list)?
 * Audio: I suggest to kill the volume, balance, bass and treble fields
   from v4l2_audio and add a few controls (V4L2_CID_AUDIO_VOLUME, ...)
   instead.

  Gerd

-- 
Beware "We should", extend a hand to "How do I"...
	-- Alan Cox on /.

List:       linux-video
Subject:    [video4linux] Re: v4l api comments / questions
From:       Bill Dirks <bill.dirks () rendition ! com>
Date:       1998-11-15 23:55:20

Gerd Knorr wrote:
> Came across these problems
> 
>  * v4l2_framebuffer.base is a array if tree values.  What this is good
>    for, especially the second and third?

Triple-buffered page flipping. The video data frames arrive (video
vsync) unsynchronized with the graphics display refresh (display vsync),
so you need at least three buffers to sync the video to the display and
guarantee no tearing. (one buffer currently being scanned by the CRTC,
one buffer with the next frame ready to be flipped into place at the
next display vsync, and one buffer where the newest video frame is being
written to)


>  * v4l2_window has a "count" field, v4l2_clip has a "next" pointer.  How
>    this is supported to work?

It was just lifted from the v4l spec at the time. I would be very
interested in any suggestions or recommendations you might have
regarding any portion of the frame buffer preview controls. What would
you like to see?


>  * Audio: I suggest to kill the volume, balance, bass and treble fields
>    from v4l2_audio and add a few controls (V4L2_CID_AUDIO_VOLUME, ...)
>    instead.

<ding> Yes, I meant to do that, but forgot. It will be done.

Bill.

List:       linux-video
Subject:    [video4linux] Re: v4l api comments / questions
From:       Gerd Knorr <kraxel () goldbach ! in-berlin ! de>
Date:       1998-11-17 19:45:40

On Sun, 15 Nov 1998, Bill Dirks wrote:

> Gerd Knorr wrote:
> > Came across these problems
> > 
> >  * v4l2_framebuffer.base is a array if tree values.  What this is good
> >    for, especially the second and third?
> 
> Triple-buffered page flipping. The video data frames arrive (video
> vsync) unsynchronized with the graphics display refresh (display vsync),
> so you need at least three buffers to sync the video to the display and
> guarantee no tearing. (one buffer currently being scanned by the CRTC,
> one buffer with the next frame ready to be flipped into place at the
> next display vsync, and one buffer where the newest video frame is being
> written to)

Sounds fine.  For V4L2_FBUF_FLAG_PRIMARY proably only the first is needed?

> 
> >  * v4l2_window has a "count" field, v4l2_clip has a "next" pointer.  How
> >    this is supported to work?
> 
> It was just lifted from the v4l spec at the time. I would be very
> interested in any suggestions or recommendations you might have
> regarding any portion of the frame buffer preview controls. What would
> you like to see?

Looks fine.  I hav'nt checked how the XVideoSomething Extention of the
upcoming XFree86 4.0 works.  But this is something which you have to keep
in mind:  Video Application, X-Server and driver have to work
hand-in-hand.  The v4l2 api should be prepeared to handle this.  Maybe
Alan can comment on this...

   Gerd

List:       linux-video
Subject:    Re: [video4linux] Re: v4l api comments / questions
From:       Alan Cox <alan () cymru ! net>
Date:       1998-11-17 21:35:55

> Looks fine.  I hav'nt checked how the XVideoSomething Extention of the
> upcoming XFree86 4.0 works.  But this is something which you have to keep
> in mind:  Video Application, X-Server and driver have to work
> hand-in-hand.  The v4l2 api should be prepeared to handle this.  Maybe
> Alan can comment on this...

Which bit - Im sort oflost here

List:       linux-video
Subject:    Re: [video4linux] Re: v4l api comments / questions
From:       Gerd Knorr <kraxel () goldbach ! in-berlin ! de>
Date:       1998-11-18 20:56:04

In lists.linux.video4linux you write:

>> Looks fine.  I hav'nt checked how the XVideoSomething Extention of the
>> upcoming XFree86 4.0 works.  But this is something which you have to keep
>> in mind:  Video Application, X-Server and driver have to work
>> hand-in-hand.  The v4l2 api should be prepeared to handle this.  Maybe
>> Alan can comment on this...

>Which bit - Im sort oflost here

As far I know, you have talked to the XFree folks about this topic.

If we want to do overlay by DMA'ing YUV to some off-screen memory
and let the gfx board do colorspace conversion, scaling and displaying
of the video, we have to do quite some coordination between driver,
application and X-Server.

The application will provide some controls for tuning, bright, contrast
and tell the driver if the user changes these.  That's easy, works fine
already.

The application has to tell the X-Server "This Window here should used
for video display" (XVideoAttach ?).  It might be required to inform the
X-Server if the user changes some parameters (TV norm for example, this
changes the max. video size...). 

How does the buffer flipping work?  Guess the v4l driver has to inform
the X-Server if it has filled a buffer with a new frame, or does this
work completely in hardware?  I can't see anything for this in the API...

Are X-Server and driver supported to talk directly to each other, or
is the application always between these two?

  Gerd

-- 
Beware "We should", extend a hand to "How do I"...
	-- Alan Cox on /.

List:       linux-video
Subject:    Re: [video4linux] Re: v4l api comments / questions
From:       Alan Cox <alan () cymru ! net>
Date:       1998-11-18 21:29:47

> If we want to do overlay by DMA'ing YUV to some off-screen memory
> and let the gfx board do colorspace conversion, scaling and displaying
> of the video, we have to do quite some coordination between driver,
> application and X-Server.

Yes

> The application will provide some controls for tuning, bright, contrast
> and tell the driver if the user changes these.  That's easy, works fine
> already.

No. It tells X11. Remember X11 might be driving the overlay itself

> How does the buffer flipping work?  Guess the v4l driver has to inform
> the X-Server if it has filled a buffer with a new frame, or does this
> work completely in hardware?  I can't see anything for this in the API...

Don't know. I'd have to join the XFree core team to see the code for
this that they have done, and I don't wish to do so.

> Are X-Server and driver supported to talk directly to each other, or
> is the application always between these two?

X and driver. Because X itself may contain drivers for cards that dont need
kernel help.

Alan