GNOME Bugzilla – Bug 477683
Orca failed to bring full screen mag up.
Last modified: 2007-10-01 22:02:36 UTC
Orca failed to bring the full screen mag up. Steps to reproduce: 1. Enable Composite extension for Xorg. 2. Launch orca, and switch to magnifier tab in orca preferences window. 3. Enable magnifier, set zoom area to full screen resolution, click OK button to reload orca preferences. Expected result: Orca bring up gnome-mag full screen magnification. Actual result: Nothing happens, magnifier will not be brought up. Additional info: magnifier could be started manually in command line. This bug is found on vermillion_74/snv_72, version number of orca is 2.19.92.
Another comments: half screen magnification works well.
Confirmed. I figured the current Vermillion was missing some of Carlos' latest changes and went to build gnome-mag, but I had a failed dependency: xext. A little bit of searching let me to this entry: http://mail.opensolaris.org/pipermail/jds-notify/2007-August/004861.html > Date: 2007-08-28 13:41:09 +0000 (Tue, 28 Aug 2007) > > Added files: > trunk/patches/gnome-mag-02-no-xext-dependency.diff > Modified files: > trunk/ChangeLog > trunk/base-specs/gnome-mag.spec > > Log message: > 2007-08-28 Damien Carbery <damien.carbery at sun.com> > > * base-specs/gnome-mag.spec: Add patch, 02-no-xext-dependency, to > remove the xext dependency from configure.in. This module is not on > Solaris and gnome-mag builds without it > * patches/gnome-mag-02-no-xext-dependency.diff: Added to remove the xext > dependency. gnome-mag builds okay without xext, which is not on > Solaris. > -------------- next part -------------- > U trunk/ChangeLog > U trunk/base-specs/gnome-mag.spec > A trunk/patches/gnome-mag-02-no-xext-dependency.diff The patch in question can be found here: http://cvs.opensolaris.org/source/xref/jds/spec-files/trunk/patches/gnome-mag-02-no-xext-dependency.diff So I removed the dependency check in configure.in, and sure enough gnome-mag now "builds okay"; full-screen magnification still fails (and at least for me, causes Orca not to launch). Carlos, before I dig any deeper into this on the Orca side of things, is there any chance that the xext dependency is required for full-screen magnification when gnome-mag is launched via bonobo? And thanks in advance for letting me CC you on another Orca-Magnification bug :-)
Looking at the old configure.in it's from the Xext library that the function XShapeCombineRectangles comes from. This call is used to make mouse clicks go throw the magnifier window, so the user can interact with the desktop. If the magnifier is building okay it's taking this function from somewhere else. There are some strange things in Tim's comments, since the magnifier will use the same code path for both full-screen and half-screen magnification. @ Joanmarie: Is the magnifier fail a crash? Can you provide a stack trace?
Carlos, magnifier is not launching via bonobo when the target display dimensions are full screen. I haven't been able to get a stack trace yet. Sorry! Will suggested I try launching magnifier first, then launching Orca. When I did that, I got a series of the following error: (magnifier:1222): Gdk-CRITICAL **: file gdkpixmap-x11.c: line 153: assertion `(width != 0) && (height != 0)' failed Not sure if that's relevant or not....
(In reply to comment #4) > Carlos, magnifier is not launching via bonobo when the target display > dimensions are full screen. I haven't been able to get a stack trace yet. > Sorry! How it's being launched in this case? By command line? Or are you saying that when you launch Orca the magnifier isn't launched via bonobo? > > Will suggested I try launching magnifier first, then launching Orca. When I > did that, I got a series of the following error: > > (magnifier:1222): Gdk-CRITICAL **: file gdkpixmap-x11.c: line 153: assertion > `(width != 0) && (height != 0)' failed > > Not sure if that's relevant or not.... > A bogus behaviour IMO, but I can't say much for now, since I was unable to reproduce it here.
> How it's being launched in this case? By command line? Or are you saying that > when you launch Orca the magnifier isn't launched via bonobo? I've tried both. :-) If I launch Orca, the magnifier isn't launched via bonobo *if* my target display dimensions occupy the full screen. When I build gnome-mag on Solaris, I get these warnings. Not sure if they're relevant or not: bash-3.00$ make | grep warning "zoom-region.c", line 599: warning: statement not reached "zoom-region.c", line 1439: warning: argument #4 is incompatible with prototype: prototype: pointer to enum {GDK_MODIFIER_MASK(1543512063), GDK_RELEASE_MASK(1073741824), GDK_META_MASK(268435456), GDK_HYPER_MASK(134217728), GDK_SUPER_MASK(67108864), GDK_BUTTON5_MASK(4096), GDK_BUTTON4_MASK(2048), GDK_BUTTON3_MASK(1024), GDK_BUTTON2_MASK(512), GDK_BUTTON1_MASK(256), GDK_MOD5_MASK(128), GDK_MOD4_MASK(64), GDK_MOD3_MASK(32), GDK_MOD2_MASK(16), GDK_MOD1_MASK(8), GDK_CONTROL_MASK(4), GDK_LOCK_MASK(2), GDK_SHIFT_MASK(1)} : "/usr/include/gtk-2.0/gdk/gdkwindow.h", line 529 argument : pointer to unsigned int "zoom-region.c", line 3603: warning: syntax error: empty declaration "x11/gmag-graphical-server.c", line 113: warning: implicit function declaration: gdk_pixbuf_set_option "x11/gmag-graphical-server.c", line 287: warning: statement not reached "x11/gmag-cursor.c", line 73: warning: implicit function declaration: gdk_pixbuf_set_option
(In reply to comment #6) > > How it's being launched in this case? By command line? Or are you saying that > > when you launch Orca the magnifier isn't launched via bonobo? > > I've tried both. :-) > > If I launch Orca, the magnifier isn't launched via bonobo *if* my target > display dimensions occupy the full screen. Black magic IMO :-)! Really don't know what can be happening and as I already said, the code path for full-screen magnification is the same for half-screen, the only thing that changes is the window size. The warnings aren't relevant. Maybe the problem is in the Gdk-CRITICAL warnings that you cited in comment #6. Can you run the magnifier throw a debugger and put a breakpoint at that line in gdkpixmap-x11.c and send me the back trace?
Sorry, I would like to say comment #4 in the last post.
Created attachment 95998 [details] backtrace Carlos, is this what you're looking for??
Is exactly this. Thanks for the information, I will investigate it further as soon as I can.
Created attachment 96249 [details] [review] Patch to prevent use of magnifier if there is nothing that can be magnified I spent a fair amount of time digging into what might be causing gnome-mag to crash, and it turns out we're trying to create a zoomer when the source display bounds has a 0 dimension associated with it. If you look at the patch, it seems really nasty, but it was mostly just checking for a 0 dimension and then raising an exception as a result. Almost all the other stuff was just adding docs to help me understand the gnome-mag API again. For the overall analysis, the situation seems to be this: 1) If COMPOSITE is enabled, gnome-mag defaults the bounds of the source (the thing to be magnified) to the whole source display. 2) If COMPOSITE is not enabled, and single head is in use, the magnifier competes with screen real-estate. The result is that gnome-mag ends up adjusting the bounds of the source to reflect the area of the screen that the magnifier is not covering up. I believe this is done when we attempt to set the target-display-bounds property of the magnifier. So...the problem seems to be this: if COMPOSITE is not enabled *and* someone tries to set the zoomer to cover the entire display, there is nothing that can be magnified since the magnifier is consuming all the screen real estate. As a result, gnome-mag ends up setting one of the dimensions (the height) of the source-display-bounds to 0. We then try to create the zoomer, gnome-mag runs across this, passing a 0 height onto gdk_pixmap_new in zoom-region.c:zoom_region_create_pixmap. gdk_pixmap_new then kills us. So, this patch merely does this: if there is nothing to magnify when we attempt to initialize the magnifier, issue a SEVERE message and throw an exception (which we handle higher). Ideally, we probably should prevent the user from getting themselves into such a situation. In the event they do get into such a situation (e.g., imagine they had full screen working at one time, but someone mucked with their X Server and disabled COMPOSITE support), we probably should be more creative in how we handle the problem. For example, we might bring up a split screen magnifier, pop up an error dialog, and then pop up the Orca preferences dialog with the magnifier tab open.
Tim: > 1. Enable Composite extension for Xorg. Can you write up the instructions for doing this on OpenSolaris? I cannot seem to get COMPOSITE support working on my OpenSolaris b73 machine with Vermillion b74 installed on it.
Will, You could follow the instructions below: How to enable composite extension for xorg * Go to /etc/X11 directory * Find the file xorg.conf. If it was not there, you could copy the hidden one ".xorg.conf" to visible "xorg.conf" file. * Add following lines in xorg.conf file: Section "Extensions" Option "Composite" "Enable" EndSection * Logout and login again to restart Xorg * To check extension status with command "xdpyinfo | grep Composite". If this extension was enabled, you will get the "Composite" as return. And I also send you an email and give you the link which would navigate to jdsbj wiki page. Hoping this helps.
Cool! I had forgotten that Solaris doesn't give you an active xorg.conf by default. If I enable composite on my laptop (where I didn't have an existing xorg.conf), I have working full screen magnification via Orca and sans Will's patch. This is in Nevada 72 with ON 74 and Vermillion 75, with the latest gnome-mag and Orca from svn trunk. Tim, if you update Solaris -- and just in case, grab the latest gnome-mag and Orca from svn trunk -- and have composite enabled, do you get full screen magnification now?
Okay, I'll verify it with latest trunk build and give update by then. Thanks for your information.
I verified this bug with orca 2.20.0 and gnome-mag 0.14.10 on gnome2.20, it is not reproducible any more. Thanks for everyone's hard work on this. I'm moving this bug to close.
Thanks Tim!! Phew! I'm reopening this bug however. As Will pointed out, we should do some defensive work for this on boxes where composite is not enabled. I'll test this patch shortly.
Created attachment 96325 [details] [review] building on what Will has done.... > So, this patch merely does this: if there is nothing to magnify when we attempt > to initialize the magnifier, issue a SEVERE message and throw an exception > (which we handle higher). And as long as the user has done a 100% full screen attempt, this kicks in. However, if you are one pixel shy of a full screen (ya know, that phrase has potential, but I digress....) things still get blanked/greyed out. If you're a few pixels shy, you're mostly grey, and so on. :-( > Ideally, we probably should prevent the user from getting themselves into such > a situation. True. If gnome-mag were to expose whether or not a system were "full-screen capable", we could do some adjustment. I've opened an RFE against gnome-mag for that (bug 481009). > In the event they do get into such a situation (e.g., imagine > they had full screen working at one time, but someone mucked with their X > Server and disabled COMPOSITE support), we probably should be more creative in > how we handle the problem. For example, we might bring up a split screen > magnifier, pop up an error dialog, and then pop up the Orca preferences dialog > with the magnifier tab open. Okay, here's an attempt at getting started. This just takes what you've done, leaves most of it as is, drops the exception throwing and takes a minimalist approach to adjustment: It compares the viewport size with the magnifier source, and if the viewport is larger than the source, it reduces the size of the viewport until that's no longer the case. I haven't dealt with popping up error dialogs or the preferences dialog yet. Is this what you had in mind, or do you think we should truly split the screen? I tested it in both Solaris and Ubuntu and verified that it doesn't kick in when composite is enabled, but does when it's disabled.
Oops, forgot to add a question I was planning on asking: With or without the patches for this bug, given a system in which composite is disabled, you can split the screen but you cannot access all of the contents. When the mouse pointer crosses over into the source display area, it does not cause the zoomer contents to shift. Instead, the mouse pointer moves over the zoomer. Do you think this is something that we can fix in Orca, or does it need to be a gnome-mag fix?
> With or without the patches for this bug, given a system in which composite is > disabled, you can split the screen but you cannot access all of the contents. > When the mouse pointer crosses over into the source display area, it does not > cause the zoomer contents to shift. Instead, the mouse pointer moves over the > zoomer. Do you think this is something that we can fix in Orca, or does it > need to be a gnome-mag fix? Bug 463875 is tracking this issue. :-)
Joanie and I discussed the proposed modification to the patch with consideration mostly on single head displays without COMPOSITE enabled. The issue we came up with was that it is biased towards making the magnifier the larger thing on the display. The result of this is that the source area can end up being very small, yielding a situation where there is very little to magnify. So, the patch is trying to be nice to the user (a good thing), but ends up resulting in a bad situation for the typical use case, which is where the user thinks they've specified full screen magnification. In this case, the user can end up with a very small area of usable screen space. We agreed there are a number of opportunities to try to add some intelligence to the startup code to help prevent bad situations, but those are separate from this bug. As such, we agreed to keep the patch that fixes this bug, with a little extra documentation.
Committed to trunk and gnome-2-20 branch. Closing as FIXED.
See also bug 467664 for more information on handling the case where the magnifier ends up competing for screen real estate.