Hi Erik, There is answer from Hans De Goede: (result is: bug isn't in own driver or libv4l, but in mplayer and other applications... This word is cruel...)
>>>> I verify this bug again. Problem is about value returned from own driver > >>>> after VIDIOC_TRY_FMT ctl. Because own driver change pixelformat always to >>>> BA81 and return > this value to user space! > > So, I have a question for >>>> you. Is these behaviour correct? Can driver change pixelformat > in >>>> VIDIOC_TRY_FMT ctl? > >> Yes, in VIDIOC_TRY_FMT the driver is allowed and supposed to change any >> values to reflect values which the driver *supports*, so assuming the m5602 >> only supports BA81, then TRY_FMT returning this is normal and correct. >> > > Are you sure? > Realy can driver change pixel format, or sizes only? > In http://lwn.net/Articles/227533/ is: > > "..... If the application has requested something impossible, the > driver should return -EINVAL. > ..... On the other hand, the driver can adjust SIZE FIELDS to match an > image size supported > by the hardware; ...." > I'm afraid that that lwn article is outright wrong (and someone should mail Jon about this), the one true document on the V4L2 API is the V4L2 API doc: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API Specifically: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/r10944.htm "Finally the VIDIOC_S_FMT ioctl returns the current format parameters as VIDIOC_G_FMT does. Very simple, inflexible devices may even ignore all input and always return the default parameters." Notice the "inflexible devices may even ignore all input and always return the default parameters" Also see the section about return values: "Return Value On success 0 is returned, on error -1 and the errno variable is set appropriately: EBUSY The data format cannot be changed at this time, for example because I/O is already in progress. EINVAL The struct v4l2_format type field is invalid, the requested buffer type not supported" These retvals are for both TRY_FMT and S_FMT. Also note that we recently have had several (short) discussions about this on the list, and the outcome was the -EINVAL is only for unsupported buffer types. IOW if the given fmt.pix.pixelformat cannot be produced, then the driver should change the pixelformat to something which it can produce and return 0! So the application needs to check that fmt.pix.pixelformat is what it wants it to be after calling S_FMT or TRY_FMT and many applications do. >> What app are you seeing problems with, and which problems exactly, if you >> give me some more detail I'm sure I can help. Also keep in mind most v4l >> apps are pretty buggy. Some bugs we can work around (like I did in 0.5.1 for >> skype blindly expecting YV12 320x240 to be available on all cams), other >> bugs require patching the apps. >> > > Please, see this code way (trace): > > * User program call ioctl VIDIOC_S_FMT with format YV12 for example. > * In library (on line libv4l2.c:736) is set "dest_fmt" to YV12 > * After (if conversion is enable) call function "v4lconvert_try_format", > defined in file > libv4lconvert.c on line 175... > * if requested format isn't supported by library (YU12, RGB3 or BGR3), > call VIDIOC_TRY_FMT on driver (libv4lconvert.c:186) with pointer to > dest_fmt! > * Driver return zero (OK) and set parameter to its supported format (in this > case to BA81) > * After that is "dest_fmt" equal BA81 and src_fmt too. > * We return to libv4l2.c to line 748. "result" is zero, src_fmt and dest_fmt > are BA81... > > So, user program set YV12 format, this call return zero (OK) and after will > get data > in BA81 format... Mplayer crasch in this chaos :) > Well blame mplayer, it is not using the API in the right way. Regards, Hans ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ M560x-driver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/m560x-driver-devel
