Created attachment 92768 [details]
xorg configuration file

> Steps to reproduce:
> 1. Prepare a box with two physical monitor.

All Orca is doing in attempting to set the displays is the following in mag.py:

    try:
        _magnifier.TargetDisplay = settings.magTargetDisplay
    except:
        pass

    try:
        _magnifier.SourceDisplay = settings.magSourceDisplay
    except:
        pass

Unfortunately, I don't have a dual head machine to test with.  :-(  Anyone else have one?

In the meantime -- Tim, if you run gnome-mag on its own, are you able to reliably set its source and target displays to different heads?

 
> Unfortunately, I don't have a dual head machine to test with.  :-(  Anyone else
> have one?

I suppose I can take my tri-head machine and sever a head. ;-)  Currently I'm using Xinerama, and I'm not the best at Xorg stuff... But I see that Tim has posted his (Thanks Tim!!).    I can take a look at it later today/this evening and at least try the things you're suggesting Will.  I suppose it's about time I figure out how magnification works.... :-)

I'm missing Xinerama already.... <mutter>THREE top panels</mutter>
;-) ;-) ;-) ;-)

What I know so far is this:

1. If I start gnome-mag from a terminal window AND I specify the full screen option along with the source and targets, I can cause the source to be magnified on the target.

e.g. magnifier -f -t :0.0 -s :0.2 works

2. If I don't specify full screen, things don't magnify. 

e.g. magnifier -t :0.0 -s :0.1 (typed within gnome-terminal from :0.2), cause gnome-mag to launch, no magnification to be used, and the following to be output to the terminal window:

** Message: added event source to xfixes cursor-notify connection
** Message: added event source to composite connection
initial viewport 1680 1050

3.  If I don't specify full screen, things might also dump core:

e.g. magnifier -t :0.0 -s :0.2 (typed within gnome-terminal from :0.2)

(magnifier:11417): Bonobo-WARNING **: Assigning a default value to a non readable property 'source-display-screen'

(magnifier:11417): Bonobo-WARNING **: Assigning a default value to a non readable property 'target-display-screen'

** Message: added event source to xfixes cursor-notify connection
** Message: added event source to composite connection
initial viewport 1680 1050

Gdk-ERROR **: The program 'magnifier' received an X Window System error.
This probably reflects a bug in the program.
The error was '167'.
  (Details: serial 580 error_code 167 request_code 152 minor_code 12)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...
Trace/breakpoint trap (core dumped)

4.  No matter what I specify for the source and target in Orca, we seem to be failing when setting the source display.

> 3.  If I don't specify full screen, things might also dump core:
> 
> e.g. magnifier -t :0.0 -s :0.2 (typed within gnome-terminal from :0.2)

Does it dump core always if full screen is not used?

> 4.  No matter what I specify for the source and target in Orca, we seem to be
> failing when setting the source display.

Orca launches gnome-mag via Bonobo activation.  The thing that controls how gnome-mag is started is the "exe" line in /usr/lib/bonobo/servers/GNOME_Magnifier.server:

                   type="exe" location="/usr/bin/magnifier --ignore-composite">

So...if "/usr/bin/magnifier --ignore-composite" pukes, then there's nothing Orca can do.  :-(  I've seen some activity regarding gnome-mag bug 452159, though I haven't studied it in enough detail to know if it might be related to this bug.

> Does it dump core always if full screen is not used?

Nope.  But it doesn't magnify either. See point 2.

> So...if "/usr/bin/magnifier --ignore-composite" pukes, 

Ah, yes, that seems to reliably puke if typed just as you have it.

> Orca can do.  :-(  I've seen some activity regarding gnome-mag bug 452159,
> though I haven't studied it in enough detail to know if it might be related to
> this bug.

Well, I don't know how much sense I'll be able to make of it, but I'll look. :-)  Thanks for the tip!

The fix for bug 452159 seems to cause the --ignore-composite pukage to no longer be present.  It doesn't seem to help this bug, however.  Still investigating....

Hi Joan and Will,

Thanks for your investigation on this bug. I'd like to give some updates and tips for it here too:

1. For crashing problem
Carlos who is the gnome-mag maintainer has the patch for this, and he has committed this patch. We might need to get the latest trunk code for testing. This might not be reproducible any more.

2. For full screen magnification
This feature depends the xorg composite extension if we do not clarify the source and target screen. So, we need xserver->xorg 7.2 or above (run command: /usr/X11/bin/Xorg -version). At same time, we need to enable composite extension in xorg.conf (like what I've post previous). But if we have dual head configuration, this is not necessary for full screen mag, we could put mag screen to another monitor to implement full screen mag.

Please feel free to comment if it still doesn't work for you.

Thank you!

Hi Tim.

> This might not be reproducible any more.

I'm using the latest from trunk now.  *The crashing* is no longer a problem, but when Orca attempts to set _magnifier.SourceDisplay, it fails.  I *think* it's failing in magnifier.c somewhere in magnifier_set_property(), but I'm too unfamiliar with gnome-mag. :-(

Tim, if you have the latest everything, can you still reproduce this bug.  If you cannot, I say we call it WORKSFORME and be done with it. :-)  But assuming you still can reproduce it with everything from trunk, I think it would be really handy if Carlos could chime in so I'm adding him to the CC list.   (Thanks in advance Carlos!).

> So, we need xserver->xorg 7.2 or above (run command:
> /usr/X11/bin/Xorg -version).

Here's what I get (numbers don't seem to jive with 7.2....):

X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Linux Ubuntu
Current Operating System: Linux blockhead 2.6.22-9-generic #1 SMP Mon Jul 30 18:00:27 GMT 2007 i686
Build Date: 26 July 2007

> But if we have dual head  configuration, this is not necessary 
> for full screen mag, we could put mag screen to another monitor 
> to implement full screen mag.

That's what I'm attempting to do.  Mind you it's with a tri-head.... But I'm only using one head as the source and another head as the target.  In this environment, if I call magnifier from the command line, I can cause it to magnify the screen to another monitor.  However, if I attempt to do the same thing through Orca, setting the SourceDisplay fails 100% of the time.

Carlos, any ideas?  Thanks!

Hi,

I also don't know much about orca internals, so I can't say why I'm getting the following output when using target display different from source display (I'm using a dummy driver to simulate two displays):

Traceback (most recent call last):  File "/usr/lib/python2.5/site-packages/orca/mag.py", line 554, in init    applySettings()  File "/usr/lib/python2.5/site-packages/orca/mag.py", line 302, in applySettings
    magnifierPBag = _magnifier.getProperties()
COMM_FAILURE


Traceback (most recent call last):

+ Trace 152090

Could not initialize connection to magnifier.

** (orca:15650): WARNING **: Invalid object type load-complete


** (orca:15650): WARNING **: Invalid object type load-stopped


** (orca:15650): WARNING **: Invalid object type reload

If after this I set the target and source display to empty or :0.0 I get a functional magnifier, except that sometimes I get some parts of the screen black, something that appear to be related with bug #434660, but after using the desktop for a while, the problem disappear.

From what I experienced here, I don't know if this is a bug in gnome-mag, since , for example, I can start gnome-mag, with the following command:

#: magnifier -fm

and then use the control-client application, that is in the test folder of the gnome-mag source tree to set the source display to :0.1 as follow:

#: ./control-client s:0.1

Although this worked, the output is not the desired, since damage aren't tracked properly after this last operation and the desktop becomes practically unusable. I will open a bug in gnome-mag against it and investigate it as soon as possible.

Hi Carlos.  Thanks for looking at this!  

I haven't tried using a dummy driver yet so I'm not getting the error you cite.  I'll look at that a bit later today.  In the meantime, I started adding debugging code to magnifier.c in order to try to learn what was taking place and how things worked. 

It *seems to me* that when Orca is trying to set the source display impl_magnifier_set_source_display() gets called.  This method doesn't seem to get called when I launch magnifier from the command line (e.g. magnifier -f -t :0.1 -s :0.2)

It also seems like we're good up to this point within impl_magnifier_set_source_display():

	if (strcmp (full_display_string, magnifier->source_display_name)) {

I *think* where things are going wrong is in the code that immediately follows:

 	    magnifier_set_property (magnifier->property_bag,
				    arg,
				    MAGNIFIER_SOURCE_DISPLAY_PROP,
				    ev,
				    magnifier); 

because the debug statement I inserted immediately before magnifier_set_property() was called and the one I inserted immediately after it was not called.  If that sounds silly, please forgive me.  I'm one of those "community contributors" who's learning as she goes -- oh and who doesn't (yet) know C.  :-)  Anyhoo, I was in the process of pursuing this further by examining magnifier_set_property() when I was made aware of some Firefox issues that needed addressing so I had to put this issue aside.

I don't know if that helps at all or not, but I figured it was worth a try. :-)

Thanks again!

Hi Joanmarie,

I think that I was able to reproduce the bug here, but only to be certain that we are talking about the same bug do the following, please:

open a terminal and start the magnifier with the command #: magnifier --ignore-composite --override-redirect

then start orca (make sure it will load the source and target that make the bug appear).

In this case the magnifier worked normally?

now close everything and run the magnifier without any argument and open orca again. The magnifier crash, isn't is?

> In this case the magnifier worked normally?

For now, let's go with "differently". :-)  In this case, we are apparently successfully setting the SourceDisplay because I am not getting the error I was.  I'm still not getting magnification though.  I'm not sure if that's Orca or magnifier or me/my setup.  But I get errors such as this:

** (magnifier:7249): WARNING **: Bad bounds request (0,0 to 0,507), ignoring.
 
> now close everything and run the magnifier without any argument and open 
> orca again. The magnifier crash, isn't is?

Yup, sure does!

Gdk-ERROR **: The program 'magnifier' received an X Window System error.
This probably reflects a bug in the program.
The error was '167'.
  (Details: serial 27 error_code 167 request_code 152 minor_code 10)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...

(In reply to comment #13)
> > In this case the magnifier worked normally?
> 
> For now, let's go with "differently". :-)  In this case, we are apparently
> successfully setting the SourceDisplay because I am not getting the error I
> was.  I'm still not getting magnification though.  I'm not sure if that's Orca
> or magnifier or me/my setup.  But I get errors such as this:
> 
> ** (magnifier:7249): WARNING **: Bad bounds request (0,0 to 0,507), ignoring.
> 

This WARNING is generated when the ROI (Region Of Interest) passed to the magnifier are in an unexpected way. Although Orca sometimes passes some of they, they are very infrequently, AFAICT, since I get only one warning about this per magnifier configuration.

This WARNING appeared in the terminal where you launch gnome-mag. From the terminal that you launch Orca don't you get any output that can indicate an error?

Hi Joanmarie,

I just opened a bug #462890 against it in gnome-mag and published a patch. If you can test it, I will be very thankful.

Thanks Carlos.  As I commented on bug #462890, that made the crash go away.  However, I'm still getting the bad bounds requests.  Anywhere I move the mouse generates them and I still don't have magnification.   I'll keep looking but if you have any ideas/suggestions they are most certainly welcome.  :-)

AHA!  I altered the Zoomer Position in Orca and now things seem to be working.  I don't yet know if they're working perfectly.  But things are looking up.  :-)

Based on this, on the Orca side of things, we probably should be doing some checking to be sure that we're not sending bogus Zoomer Positions to magnifier. :-)

Tim, could you please try Carlos' patch to bug #462890 and see if that solves the problem you reported?  Thanks much!

Hi Joan,

I tried the patch which Carlos made to bug #462890, it fixed this bug. I'd like to move this bug to FIXED. If you have any problem, please feel free to open it.
Thanks for everyone's great work!