bcm2835-v4l2 works incorrectly without preview

[pbugalski]

This issue was discovered as a result of this discussion: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=62364&p=813478
Generally, if you capture video with preview on the screen module works fine. Unfortunately, if you turn off preview, white balance and exposition parameters are ignored and set to automatic.
To reproduce run:
v4l2-ctl -v width=1024,height=768,pixelformat=I420
v4l2-ctl --set-ctrl=white_balance_auto_preset=0,red_balance=5000,blue_balance=1500
v4l2-ctl --set-ctrl=brightness=55,contrast=15,saturation=0,horizontal_flip=1,vertical_flip=1,power_line_frequency=1,sharpness=0,color_effects=0,rotate=0,color_effects_cbcr=32896
v4l2-ctl --set-ctrl=auto_exposure=1,exposure_time_absolute=300,auto_exposure_bias=12,iso_sensitivity=1
v4l2-ctl -p 10
v4l2-ctl --stream-mmap=3 --stream-skip=2 --stream-to=./test.yuv --stream-count=4

As a result video will be captured with automatic white-balance (instead of reddish). If you turn on overlay, result will be correct.
Also system log says that something goes wrong without overlay (preview):

[pbugalski]

bcm2835-v4l.txt

[pbugalski]

The reason of problem is described in RaspiCam Documentation (https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiCamDocs.odt):
"The preview display is optional, but can be used full screen or directed to a specific rectangular area on the display. If preview is disabled, the null_sink component is used to 'absorb' the preview frames. It is necessary for the camera to produce preview frames even if not required for display, as they are used for calculating exposure and white balance settings."

I have patch for bcm2835-v4l, which solves this issue.

[popcornmix]

Ping @6by9

[6by9]

You've quoted a stack dump, but without the line immediately before it which will tell you what the warning was.
It looks identical to #817 where an example stack for that error is given, complete with the

that is the warning that triggered the kernel to get mildly upset. (In this case the kernel cleans up anyway - a buffer was just getting dropped).
If you still have an issue with a warning being produced on the latest kernel, please raise a new issue for it - multiple issues under one logged issue gets very confusing and/or things get missed.

As to manual white balance not being applied if preview is not running, I've already said on the forum posts that it is really a firmware bug that needs to be addressed. Adding null_sink is a bodge (but then again so is the 300ms delay written into the start_streaming handling of the driver if preview isn't enabled, but at least it means the first few frames have reasonable settings).

Enabling null_sink will also compromise JPEG/stills port capture speed as the burst mode flag isn't being requested anywhere, so the sensor will be constantly switching modes. Users of the driver are generally aware that "stills mode" captures have AGC and AWB locked, and there is a way of configuring when stills mode is available, so changing behaviour now is likely to cause major complaints.

I have some time off this coming week (16-20th), so will be looking at Pi firmware issues. That should include this one.

[pbugalski]

I wasn't interested about this stuck dump - my main target was AWB problem. But it is very easy to reproduce it on 4.1.12, you can see dump in attached file. It looks very similar to #817 in fact.

Maybe my solution is not perfect, but at least fixes AWB problem and makes stack dump disappear. If firmware wouldn't request null_sink it is good idea to remove it, but at the moment it may be better to have workaround than incorrectly working code.

About the still mode, you may be right, I didn't double check it. So it may be the case. But I disagree with idea of waiting for Broadcom to answer, it may take ages.
stack_dump.txt

[pelwell]

Perhaps you haven't heard, but as far as 2835 is concerned there is no Broadcom anymore - just Raspberry Pi and its supporters.

[6by9]

You quoted something in a report, therefore that has to be taken as something of interest - we're not mind-readers.
It appears that the fix to #817 didn't get merged to the 4.1.y branch, so the is a regression that is useful to know about. I've reopened that issue.

As I have strong suspicions that your patch will affect others on stills mode captures, I'm afraid it can't be merged until we have an answer one way or other. Regressions on things that are working is worse than misbehaviour on things that have never worked.
I have said I will look at it in the next week for a proper fix - please be patient.

The use of null_sink from raspistill/vid wasn't the greatest of moves by those who wrote those demo apps. It is true that something needs to request frames to take reasonable stills, but for video mode that should be totally unnecessary. V4L2 is running in video mode more often than not.

[pbugalski]

I have idea how to improve this patch. I agree that default behavior have changed and it's my fault. But I can set by default AWB mode and it should behave the same way like now to the user. Only if someone change to manual it will stay in manual mode as it should. The same way it will be after fix in firmware. What do you think about this solution?

[R4C3R]

Is there any progress on finding a proper solution?

[6by9]

The referenced commit should have fixed setting manual AWB gains and resolved this issue. Waiting for someone to confirm it. It worked well for me via qv4l2, though switching back to auto WB when in stills mode doesn't work.

[R4C3R]

Just downloaded the new kernel and indeed, I can confirm that it works! Thank you for all your efforts!
And a special thank you to pbugalski .

[6by9]

@popcornmix Please resolve.