On 01/06/2013 12:32 PM, Mauro Carvalho Chehab wrote:
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrocki<sylvester.nawrocki@xxxxxxxxx> escreveu:
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling of VIDIOC_S_FMT
I'll drop this one for now. Devin raised a point: such changes would break
existing applications.
So, we'll need to revisit this topic before changing the drivers.
Btw, I failed to find the corresponding patch at patchwork:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=VIDIOC_S_FMT
So, its status update may be wrong after flushing your pwclient commands.
Hmm, I got this patch from Tomasz by e-mail and added it to the pull
request.
I think it wasn't sent to the mailing list, but I noticed it only after
sending you the pull requests, when was preparing the pwclient commands.
I've just posted it now, sorry. The link is here:
http://patchwork.linuxtv.org/patch/16143
Tomasz created this patch specifically for the purpose of format negotiation
in video pipeline in the application we used to test various scenarios with
DMABUF. I agree this patch has a potential of breaking buggy user space
applications. I can't see other solution for it right now, there seems even
to be no possibility to return some flag in VIDIOC_S_FMT indicating that
format has been modified and is valid, when -EINVAL was returned. This
sounds
ugly anyway, but could ensure backward compatibility for applications that
exppect EINVAL when format has been changed. BTW, I wonder if it is only
fourcc,
or other format parameters as well - like width, height, some applications
expect to get EINVAL when those have changed.
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
