See below for an update on this - so no one spends too much time duplicating work.
On Thursday 19 July 2007 19:30, Laurent Pinchart wrote: > > Quick question on overlays - I assume these aren't planned as I don't see > > the copy providing a performance benefit. I've done some reading and > > searching and I'm assuming it would be CPU driven for a USB device? Are > > you able to confirm this, or tell me I'm wrong? > > If by overlay you mean writing to the graphic memory, you're right, this > isn't planned. There is no way a USB device could write to the GPU, so this > doesn't make sense. > > > The Flash Player is a particularly awkward application in this regard - > > I've started to look at providing a kind of software driven overlay at > > the kernel level setup via the X V4L extension because flash seems to > > rely on the overlay for aspects of it's operation. > > Really ? Should flash be added to the list of "broken by design" > software ? :-) > > > Although now I'm beginning to > > think a more logical approach might be to try and patch the flash support > > library to work with the UVC driver and no overlay (but I'm not certain > > that this is supported - even though there's example code available). > > I'm not familiar with flash. Do they provide an open-source user library to > access video devices ? http://www.kaourantin.net/flashplayer/flashsupport.c For Flash: 1. Overlays may or may not be relevant - it's unclear from the information at my disposal. The ioctl is called, but that may be the default behaviour (as querycap is also called before that - which should make clear the device has no overlay). 2. I patched libflashsupport.c (the library provided by Adobe) to support our cameras (in particular the YUYV image format). Watching the process - the library dynamically loaded and the init routine is called (FPX_Init). The function pointers for the camera are set - but no calls are made. To be fair though - the web page says this will be the case. http://labs.adobe.com/wiki/index.php/Flash_Player:Additional_Interface_Support_for_Linux I'm guessing the code included in the library probably isn't the code actually in flash plugin library for V4L. Although if it was, adding support for a planar format may help. I think the best thing I can do at this stage is find out where to log what I think is a flash plugin bug. If anyone spots anything below, let me know. Chris For those interested - here's some output from dmesg (I can't see it setting the format). uvcvideo: uvc_v4l2_open uvcvideo: uvc_v4l2_ioctl v4l1 ioctl VIDIOCGCAP, dir=r- (0x803c7601) v4l2 ioctl VIDIOC_QUERYCAP, dir=r- (0x80685600) v4l2 ioctl VIDIOC_ENUMINPUT, dir=rw (0xc04c561a) v4l2 ioctl VIDIOC_ENUMINPUT, dir=rw (0xc04c561a) v4l2 ioctl VIDIOC_ENUM_FMT, dir=rw (0xc0405602) v4l2 ioctl VIDIOC_TRY_FMT, dir=rw (0xc0cc5640) uvcvideo: Trying format 0x47504a4d (MJPG): 10000x10000. uvcvideo: Using default frame interval 33333.3 us (30.0 fps). uvcvideo: uvc_v4l2_ioctl v4l1 ioctl VIDIOCGPICT, dir=r- (0x800e7606) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_G_FMT, dir=rw (0xc0cc5604) uvcvideo: uvc_v4l2_ioctl v4l1 ioctl VIDIOCGWIN, dir=r- (0x80207609) v4l2 ioctl VIDIOC_G_FMT, dir=rw (0xc0cc5604) v4l2 ioctl VIDIOC_G_FMT, dir=rw (0xc0cc5604) uvcvideo: uvc_v4l2_release uvcvideo: uvc_v4l2_open uvcvideo: uvc_v4l2_ioctl v4l1 ioctl VIDIOCGCAP, dir=r- (0x803c7601) v4l2 ioctl VIDIOC_QUERYCAP, dir=r- (0x80685600) v4l2 ioctl VIDIOC_ENUMINPUT, dir=rw (0xc04c561a) v4l2 ioctl VIDIOC_ENUMINPUT, dir=rw (0xc04c561a) v4l2 ioctl VIDIOC_ENUM_FMT, dir=rw (0xc0405602) v4l2 ioctl VIDIOC_TRY_FMT, dir=rw (0xc0cc5640) uvcvideo: Trying format 0x47504a4d (MJPG): 10000x10000. uvcvideo: Using default frame interval 33333.3 us (30.0 fps). uvcvideo: uvc_v4l2_ioctl v4l1 ioctl VIDIOCGPICT, dir=r- (0x800e7606) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_G_FMT, dir=rw (0xc0cc5604) uvcvideo: uvc_v4l2_ioctl v4l1 ioctl VIDIOCGWIN, dir=r- (0x80207609) v4l2 ioctl VIDIOC_G_FMT, dir=rw (0xc0cc5604) v4l2 ioctl VIDIOC_G_FMT, dir=rw (0xc0cc5604) uvcvideo: uvc_v4l2_ioctl v4l1 ioctl VIDIOCGPICT, dir=r- (0x800e7606) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_QUERYCTRL, dir=rw (0xc0445624) v4l2 ioctl VIDIOC_G_CTRL, dir=rw (0xc008561b) v4l2 ioctl VIDIOC_G_FMT, dir=rw (0xc0cc5604) uvcvideo: uvc_v4l2_ioctl v4l1 ioctl VIDIOCCAPTURE, dir=-w (0x40047608) v4l2 ioctl VIDIOC_OVERLAY, dir=-w (0x4004560e) uvcvideo: Unsupported ioctl 0x4004560e uvcvideo: uvc_v4l2_read uvcvideo: uvc_v4l2_read: allocating buffers uvcvideo: uvc_v4l2_read: turning on stream uvcvideo: uvc_v4l2_read: queueing buffers uvcvideo: Queuing buffer 0. uvcvideo: Queuing buffer 1. uvcvideo: Dequeuing buffer 0. uvcvideo: Frame complete (EOF found). uvcvideo: EOF in empty payload. uvcvideo: uvc_v4l2_read: queue.mem: f8e18000 m.offset: 0 length: 2621440 bytesused: 76370 count: 1228800 uvcvideo: uvc_v4l2_read: count: 76370 uvcvideo: uvc_v4l2_read: requeueing buffer uvcvideo: Queuing buffer 0. uvcvideo: uvc_v4l2_read uvcvideo: Dequeuing buffer 1. uvcvideo: Frame complete (EOF found). uvcvideo: EOF in empty payload. _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel