maemo.org Bugzilla – Bug 6194
Shutter release button does not always work
Last modified: 2010-03-15 20:54:25 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 1.2009.41-10 STEPS TO REPRODUCE THE PROBLEM: 1. Open camera by opening the lens cover 2. Take a photo by pressing the shutter release button EXPECTED OUTCOME: Camera should always focus and take a photo. ACTUAL OUTCOME: Nothing happens, no attempt at focusing nor shutter release. No error messages are displayed. It is simply as if the button was never pressed. REPRODUCIBILITY: sometimes (rare) OTHER COMMENTS: I get this problem every so often when using the camera. Usually if I close the camera and open it again, the button works. Yesterday this happened while I was looking for mushrooms. I found a wonderful mushroom and wanted to take a photo, but the shutter release did nothing. It was raining, so I didn't want to spend time trying to make it work, and ultimately missed the photo opportunity. I just noticed that dmesg displays various GPIO events during camera use (GPIO 110 for lens cover, GPIO 68 and 69 for the focus and shutter release). I will attach the dmesg output the next time I encounter this problem.
The Shutter button has two levels - maybe you have not pressed it fully?
(In reply to comment #1) > The Shutter button has two levels - maybe you have not pressed it fully? I'm aware that you press it half-way to focus and fully to trigger the shutter release. It was definitely misbehaving, as I had been taking photos throughout the day with no problems, and afterwards as well. As I said I will post a dmesg the next time it happens with the GPIO messages. Anything else that would help?
syslog is probably better than dmesg here...
Created an attachment (id=1611) [details] Syslog showing ignored GPIO events I have encountered this issue probably 3 or 4 times since I've filed this bug. Attached is the syslog from today when I had the problem twice in a row, and then finally the shutter button started working. I had been taking photos during the day during another mushroom hunting expedition. I had very few other applications running, so nothing was taxing the CPU. Line 126 shows that I open the camera shutter to take a photo. 4 seconds later, at line 132, I attempt to focus on the subject by pressing the shutter release half-way. This continues for some time, as I am making sure I am not imagining things, until line 147, where I completely depress the shutter release. Line 158 shows me attempting to focus again and take a photo. Notice these next four GPIO events (lines 158-161) occur at 15:41:06. Then, at lines 162-165, another attempted photo fails, ending at time 15:41:07. This is at most two seconds since the last attempt started. It should be obvious here that it is impossible to take two photos in a row within two seconds, taking into consideration the "Processing image" screen that is displayed followed by the image preview (mine is set to two second preview). I do some more fiddling trying to make the shutter release work, in vain, and close the lens cover at line 198. Only 3 minutes later, I open the lens cover again at line 243 and try to take two more photos, which fail. As we can see the time between them is only 3 seconds, which I believe should not be possible if a photo were in fact taken on the first attempt. I close the lens cover again at line 267. Finally, at line 273, I open the lens cover for a third time and depress the shutter release fully, taking a photo successfully. This is evidenced by the fact that at line 281, the media tracker seems to start indexing the newly taken photo.
Adding myself to CC. I've come to this problem every now an then. AFAIK, Camera listens to HAL events through DBus, not GPIO, so maybe there is a problem in HAL or in the HAL-DBus. Camera team should take a close look to this problem.
Also see bug 6918 which might be related.
*** This bug has been confirmed by popular vote. ***
This has been fixed in the internal build version 10.2010.08-5 (Note: 2009/2010 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).