Hi Anthony,
Thank you for reporting this issue, if I recall correctly it has been already reported in the past but the bug was closed because the reporter didn't experience it anymore.
I cannot reproduce it here and I believe it's something related to your specific hardware.
Could you tell us which video card do you have? Are you using a compositing manager (metacity composite, compiz, or another one...)?

I have a little suspect of what might cause this strange behavior but I need your help to better understand it:
Whould you mind checking out gnome-2-24 branch from cheese SVN, apply the patch I'm attaching and run cheese -v > logfile?
Then attach the log here, it should contain some useful debug info to understand what it's happening. Be careful to attach the log only if you're able to reproduce the issue again.
Thank you

Filippo

Created attachment 125572 [details] [review]
add some debug to cheese-flash

Well, I can no longer reproduce this bug since I manually ran `apt-get source cheese`, and edited cheese-webcam.c so it didn't call the flash function before recompiling and living happily ever after. If it is still of any use, it is an Intel Mesa video card on a Gateway MT6705 laptop. I do not wish to upgrade to a nightly build of GNOME right now (required in order to run svn cheese, from what `./configure` told me) as this is also my work computer and any bugs affect me critically (sorry). If there are any logs left from the old (still present) cheese binary, let me know where they would be and I'll happily post them. I do use compiz fusion as my WM of choice, but as I said - switching back to normal, flat metacity yielded the same results. It is a fairly "vanilla" Ubuntu 8.10 installation, although I set my X server to bypass the kernel's framebuffer in my configuration (this, I believe, was not the default). I will continue to help as much as I can, though.

are you using a cheese 2.24 version? 

Yes, thats why I filed it here.

Hi Anthony,
There shouldn't be any need to install it from gnome svn. Would you mind applying the patch on the source retrieved from apt? It should apply cleanly there too.
It's just some more debug, it shouldn't cause any issue and you won't even see it if you don't run cheese with -v option. Thank you.

Are you *really* sure that plain metacity (with disabled compositor) yields the same result? If so my idea about the source of this bug could be wrong, please don't give up on helping us... commenting out the source would solve your own issue but we have a chance here to solve it for all the users (it's not the first time someone reported a behavior like this but it seems it's someway random and usually disappears with some upgrade, so probably it's related to the video driver).

*** Bug 567410 has been marked as a duplicate of this bug. ***

Using Cheese 2.24.1, and I can confirm that the flash also stays on with composite effects disabled.

I can only stress that the flash effect works fine when it's initiated by pressing [space].

Thks Filippo, i've already make the cnages and comments needed at LP.

by the way, do you have a deb package with the debug patches so it gets easier for the reporters to provide the output??

I have the debian source package. I have applied the patch, build and installed, but I get no output by using neither -v nor -vv. I tried for a long time to see if there was anything I could do to enable debugging upon ./configure. Is there?

(In reply to comment #10)
> I have the debian source package. I have applied the patch, build and
> installed, but I get no output by using neither -v nor -vv. I tried for a long
> time to see if there was anything I could do to enable debugging upon
> ./configure. Is there?

Ok, that seems a new bug, would you mind opening one in bugzilla?
Anyway you should be able to fix it launching "mkdir -p ~/.gnome2/cheese"
Then you should be able to see debug messages with -v.

I have attached debug output! "mkdir -p ~/.gnome2/cheese" was what was needed to fix it.

Created attachment 126341 [details]
Debugging output from cheese. First picture is take with [space] and then with mouseclick, and then I kill cheese.

Quite strange... the second time it seems that cheese_flash_start_fade never gets called.
I'll try to come up with a more detailed debug patch.
Anyway, would you mind repeating the same test with compositor disabled?

Created attachment 126343 [details]
Debugging output with compositing disabled.

Same procedure as last debug.. first [space], then mouse click.

Hi All, :-) 
the needed informations is already on ubuntu's launchpad:

on photo capture cheese blanks the screen until logout
https://bugs.launchpad.net/gconf/+bug/297890

You can reproduce this error in Ubuntu Intrepid or Jaunty (with whole screen is white and a mouse pointer) by create a new user, and adding this line

<entry name="accessibility" mtime="1225138994" type="bool" value="true"/>

to

/home/username/.gconf/desktop/gnome/interface/%gconf.xml

You can find a workaround:modificated source (I not tried)
And a next bug causes by this "wrong" entry:

Synaptic Preferences Window hangs on clicking Ok or Apply
https://bugs.launchpad.net/gconf/+bug/174570

best regards: pitwalker

Ok thanks pitwalker, I can confirm that the bug occurs and is 100% reproducible only when a11y is enabled. You can try yourself running:

/usr/lib/at-spi/at-spi-registryd&
GTK_MODULES=gail:atk-bridge cheese

Take a photo, the screen will go white, press Alt+TAB to switch to the terminal and Ctrl+C to kill cheese.
I'm still not sure about the reason of this odd behaviour, it could have something to do with the input region setting or with our expose callback, adding accessibility keyword maybe some a11y guy have a clue about this.

Some more information:
it seems that, with a11y enabled, cheese_flash_start_fade, attached with g_timeout_add never gets called. I tried increasing priority but no success.
Also it seems that the issue never happens if you press Take Photo button hitting spacebar and happens almost every time if you click on it with the mouse.

Hi Filippo Argiolas,

If I login to gnome with 
a bad /home/username/.gconf/desktop/gnome/interface/%gconf.xml:
press Take Photo button hitting spacebar -> never success

You are not allowed to post to this mailing list, and your message has
been automatically rejected.

You have to subscribe the list to post messages to it. To subscribe
yourself, please follow the instructions listed here:
http://mail.gnome.org/mailman/listinfo/cheese-list

From: 	Michael Meeks <michael.meeks@novell.com>
Reply-to: 	michael.meeks@novell.com
To: 	Filippo Argiolas <fargiolas@gnome.org>
Cc: 	gnome-accessibility-list@gnome.org, cheese-list@gnome.org
Subject: 	Re: Help needed with an a11y related Cheese bug
Date: 	Thu, 05 Mar 2009 09:07:25 +0000
        
        Hi Filippo,
        
        On Thu, 2009-03-05 at 08:53 +0100, Filippo Argiolas wrote:
        > I'm sending this mail because of a pretty strange cheese bug that only
        > happens if accessibility is enabled.
        
                What fun :-)
        
        > The relevant lines from cheese-flash.c are:
        > 
        >   gtk_widget_show_all (GTK_WIDGET (flash_window));
        >   flash_priv->flash_timeout_tag = g_timeout_add (FLASH_DURATION,
        > cheese_flash_start_fade, (gpointer) flash);
        
                Is this code correctly protected with the gdk mutex functions ? should
        you be using gdk_threads_add_timeout [ and it's equivalent ] everywhere
        that you do that ?
        
        > I tried to figure out what could cause this behaviour but I have no
        > knowledge about the way accessibility works so I couldn't get any far.
        > Did any of you ever heard about g_timeout_add not working with a11y enabled?
        > Any idea of what could cause this issue?
        
                So - if you are using gtk+ in a threaded fashion, there are a -lot- of
        potential interesting problems ;-) are you actually doing that ? and if
        not, why initialise gdk for thread support ?
        
HTH.        

        

(In reply to comment #20) 
>                 Is this code correctly protected with the gdk mutex functions ?
> should
>         you be using gdk_threads_add_timeout [ and it's equivalent ] everywhere
>         that you do that ?

As far as I can tell this code is run by a signal handler so the locking is done by the mainloop.
Looking at the backtrace with gdb I can tell for sure that is a locking issue.
There is a deadlock in the mainloop:

+ Trace 213215

It's stuck waiting for the mutex to be released but apparently there is someone who locked it and didn't release it.
Looking at the other threads I didn't find anything useful but I'm not so experienced with gdb usage so I can me missing something.
I tried to disable all unuseful threads (thumbnail generation, flash sound player) but the issue still happens.
Also, using gdk_threads_add_timeout instead of g_timeout_add doesn't have any sensible effect.

Fixed in trunk or at least my last commit fixes the issue here, please test it as soon as possible (ideally before thuesday) and reopen the bug if you still experience it.

2009-03-07  Filippo Argiolas <filippo.argiolas@gmail.co>

	* src/cheese-window.c:
	  Lock gdk mutex in photo-saved and video-saved callbacks
	  Those signals are emitted within a gstreamer callback so outside the
	  mainloop, hence the need for locking.
	  This fixes the flash locking issue and also the one about the grey
	  thumbview right after the flash.
	  Fixes bug #566098

The guys from gnome-a11y confirmed the bug is fixed in trunk.

*** Bug 577785 has been marked as a duplicate of this bug. ***