> There's one thing that confuses me though... if the idea here is that > available sizes may depend on factors such as pixel format (which is the > case with some USB cams), how does the driver know what format the app > calling VIDIOC_CHECK_SIZE wants? There are width and height fields in > v4l2_pix_format, which kind of nullifies the value of VIDIOC_CHECK_SIZE > in that situation. How about this. VIDIOC_G_FBUF, VIDIOC_S_FBUF - Privileged part of the overlay initialization (for input and output devices alike). VIDIOC_G_FMT, VIDIOC_S_FMT - We add v4l2_window, so these are the video or raw vbi capture, output or video overlay parameters. VIDIOC_TRY_FMT - Like VIDIOC_S_FMT, but does not change driver state. Apart of width and height this also contains pixfmt (for capturing) and x, y (overlay). Like XvQueryBestSize() this can be used to determine suitable parameters without disabling capturing or overlay. One problem is the connection to cropping/scaling. Remember S_FMT / S_WIN was defined as one end of cropping/scaling negotiation and S_CROP can change v4l2_format / v4l2_window parameters. When VIDIOC_CHECK_SIZE or _TRY_FMT work independent of cropping one cannot try a different source. The other option is to change some driver state, if only shadow parameters. Apropos overlay. What about DMA into off-screen video ram, i.e. buffers for hw scaling and overlay (frontend or backend scaler)? I suppose v4l2_framebuffer can refer to the entire video ram as it is viewed by the XF86 server: Virtual screen width times all lines that fit into video ram and are accessible by the hardware without weird tricks. Textures and pixmaps are cached in a 2d space and not all video buffers may fit in its width. A Xv driver can allocate a linear range of memory, but then bytesperline = width is different from that in struct v4l2_framebuffer.fmt. Do we need a bytesperline field in v4l2_window? If so, how will this affect planar formats? There once was a thread discussing this to no avail. The existing v4l2 spec assumes the planes follow immediately in memory and Cb/Cr bytesperline is divided according to the defined chroma subsampling. I don't think any gfx card will require planar DMA overlay, but it could matter when storing YUV 4:2:0 (to save bandwidth etc) in off-screen buffers. What about synching overlay with vga? The three base pointers in v4l2_framebuffer exist for this purpose IIRC, but the spec nowhere explains how it works. A method to sync with video (e.g. using select()) may be useful to XvPutImage into a cached PixMap too. Michael
