Hi Andreas, Thank you for the patch, On 23/11/2018 16:14, Andreas Pape wrote: > stk_start_stream can only be called successfully if stk_initialise and > stk_setup_format are called before. When using e.g. cheese it was observed > that stk_initialise and stk_setup_format have not been called before which > leads to no picture in that software whereas other tools like guvcview > worked flawlessly. This patch solves the issue when using e.g. cheese. > This one worries me a little... (but hopefully not too much) > Signed-off-by: Andreas Pape <ap@xxxxxxxxxx> > --- > drivers/media/usb/stkwebcam/stk-webcam.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c > index e61427e50525..c64928e36a5a 100644 > --- a/drivers/media/usb/stkwebcam/stk-webcam.c > +++ b/drivers/media/usb/stkwebcam/stk-webcam.c > @@ -1155,6 +1155,8 @@ static int stk_vidioc_streamon(struct file *filp, > if (dev->sio_bufs == NULL) > return -EINVAL; > dev->sequence = 0; > + stk_initialise(dev); > + stk_setup_format(dev); Glancing through the code base - this seems to imply to me that s_fmt was not set/called (presumably by cheese) as stk_setup_format() is called only by stk_vidioc_s_fmt_vid_cap() and stk_camera_resume(). Is this an issue? I presume that this means the camera will just operate in a default configuration until cheese chooses something more specific. Actually - looking further this seems to be the case, as the mode is simply stored in dev->vsettings.mode, and so this last setup stage will just ensure the configuration of the hardware matches the driver. So it seems reasonable to me - but should it be set any earlier? Perhaps not. Are there any complaints when running v4l2-compliance on this device node? > return stk_start_stream(dev); > } > > -- Regards -- Kieran
