Tech Insider					     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

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/