On Sun January 6 2013 13:41:57 Mauro Carvalho Chehab wrote: > Em Sun, 06 Jan 2013 13:34:53 +0100 > Sylwester Nawrocki <sylvester.nawrocki@xxxxxxxxx> escreveu: > > > 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. > > The patch makes the driver compliant to v4l-compilance, as its behavior asks > for such change, after some discussions we had this year in San Diego. At that > time, we all believed that such change were safe. > > However, we can't do it like proposed there (and on other patches from Hans). > > The fact is that tvtime and mythtv applications (maybe more) will fail > if the returned format is different than the requested ones, as they > don't check for the returned value. > > As no regressions on userspace are allowed, we need to re-discuss this issue. > > While this doesn't happen, I'll postpone such patches. This is a video output device. So this patch will never affect tvtime/mythtv/etc. I have no problem with this change being merged. Regards, Hans -- 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
