Em Fri, 17 Aug 2018 12:09:40 +0200 Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > On 17/08/18 12:02, Tomasz Figa wrote: > > On Thu, Aug 16, 2018 at 8:15 PM Mauro Carvalho Chehab > > <mchehab+samsung@xxxxxxxxxx> wrote: > >> > >> Em Thu, 16 Aug 2018 12:25:25 +0200 > >> Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > >> > >>> Laurent raised a few API issues/questions in his review of the documentation. > >>> > >>> I've consolidated those in this RFC. I would like to know what others think > >>> and if I should make changes. > > ... > > FYI, VIDIOC_G_(EXT_)CTRL returns EINVAL if an unsupported control is > > queried, so if we decided to keep the "cache" functionality after all, > > perhaps we should stay consistent with it? > > Reference: https://www.kernel.org/doc/html/latest/media/uapi/v4l/vidioc-g-ext-ctrls.html#return-value > > > > My suggestion would be: > > - EINVAL: the control was not in the request, (if we keep the cache > > functionality) > > - EPERM: the value is not ready, (we selected this code for Decoder > > Interface to mean that CAPTURE format is not ready, which is similar; > > perhaps that could be consistent?) > > > > Note that EINVAL would only apply to writable controls, while EPERM > > only to volatile controls, since the latter can only change due to > > request completion (non-volatile controls can only change as an effect > > of user space action). > > > > I'm inclined to just always return EPERM when calling G_EXT_CTRLS for > a request. We can always relax this in the future. > > So when a request is not yet queued G_EXT_CTRLS returns EPERM, when > queued but not completed it returns EBUSY and once completed it will > work as it does today. Works for me. Thanks, Mauro
