> How about this.
>
> VIDIOC_G_FBUF, VIDIOC_S_FBUF - Privileged part of the overlay
> initialization (for input and output devices alike).
Nothing new, right?
> VIDIOC_G_FMT, VIDIOC_S_FMT - We add v4l2_window, so these are the video
> or raw vbi capture, output or video overlay parameters.
That would also obsolete VIDIOC_G_WIN + VIDIOC_S_WIN.
> VIDIOC_TRY_FMT - Like VIDIOC_S_FMT, but does not change driver state.
Good idea, better than my approach.
> 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.
Hmm ...
> 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.
Exactly.
> 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.
The current XFree86 implementation doesn't give you a linear chunk of
memory, but allocates a rectangle like it does for pixmaps (i.e. the
padding is the same as on the visible area on the screen).
Even a linear range of memory would be easy to handle: Setup that
memory block as "screen" using VIDIOC_S_FBUF, so you can set x+y for the
window to zero.
> Do we need a bytesperline field in v4l2_window?
Don't think so.
> 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.
Thats why I dropped it, it was pretty useless as-is.
> A method to sync with video (e.g. using select())
> may be useful to XvPutImage into a cached PixMap too.
Hmm. Maybe we should continue to go the way with making overlay not
being that special any more. We could use v4l2_buffer to setup multiple
buffers within the offscreen area:
enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR = 2,
V4L2_MEMORY_OVERLAY = 3,
};
struct v4l2_requestbuffers
{
int count;
enum v4l2_buf_type type;
enum v4l2_memory memory;
__u32 reserved[2];
};
struct v4l2_buffer
{
int index;
enum v4l2_buf_type type;
__u32 bytesused;
__u32 flags;
enum v4l2_field field;
struct timeval timestamp;
struct v4l2_timecode timecode;
__u32 sequence;
/* memory range */
enum v4l2_memory memory;
union {
off_t offset;
void* userptr;
};
__u32 length;
__u32 reserved[2];
};
- V4L2_MEMORY_MMAP is the "classic" mmaping (offset+length returned
by the QUERYBUF and passed to mmap())
- V4L2_MEMORY_USERPTR allows applications to pass in pointers to
random userspace memory (userptr+length).
- V4L2_MEMORY_OVERLAY allows the applications to specify some piece
of memory within the range configured by S_FBUF (with offset being
relative to v4l2_framebuffer->base)
Then the applications can either use the classic way
"VIDIOC_OVERLAY(on/off)" or STREAMON / QBUF / DQBUF / STREAMOFF.
Maybe we should name OVERLAY PCI_PCI then, as this could be in theory
something else than a gfx card ...
Comments?
Gerd
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20
