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