GNOME Bugzilla – Bug 376047
magnifier bonobo server starts with -vz2
Last modified: 2007-03-05 17:36:37 UTC
Since we are manipulating the magnifier programatically, why does it make sense to have the magnifier first start with '-vz 2'? If the user chose certain preferences for size and location of the target display via a client program, the magnifier should be able to be started and given those settings without unnecessary flickering and window rearrangements.
Created attachment 76719 [details] [review] Removes the '-vz 2' flag
sounds reasonable. We used -v originally to work around some bugs, but that's no longer necessary AFAICT.
Created attachment 76983 [details] [review] the test program was breaked by Eitan patch, this correct they. The test programs expected the '-vz 2' flag to work properly. This patch make they work in both situations, with or without the flags.
Looks good! Just note that you are assuming the screen is 1024x768. It is possible to probe via gdk and find out the real resolution. Since it's just the test app, I think it's reasonable.
Created attachment 76992 [details] [review] This make the test programs always set magnifier window to fill the right half of the screen. Thanks for the comments Eitan, it make me check the GDK API, since I only look at how this is done in a part of gnome-mag code and major modifications will be required to achieve this behavior (vertical split) using that code, but this is really simple using the GDK API.
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.
This fix broke magnification in Orca. Please advise us on how Orca should initialize gnome-mag properly. As a starting point for discussion, the Orca magnifier code is at http://svn.gnome.org/viewcvs/orca/trunk/src/orca/mag.py?revision=1979&content-type=text%2Fplain. Thanks!
Will, I think our mag code is still working. Compare your initialization code with that in http://svn.gnome.org/viewcvs/lsr/trunk/src/Devices/GnomeMagDevice.py?view=markup
> I think our mag code is still working. Compare your initialization code with > that in > http://svn.gnome.org/viewcvs/lsr/trunk/src/Devices/GnomeMagDevice.py?view=markup I'd guess your code is still working because this patch that broke Orca was contributed by the LSR guys. ;-) You guys are probably doing something right, however, and we're probably doing something wrong. I'm just not sure what it is. All I know is that without the "-vz 2" string, the call to bonobo.get_object("OAFIID:GNOME_Magnifier_Magnifier:0.9", "GNOME/Magnifier/Magnifier") results in a COMM_FAILURE. Since this is the very first thing either of us need to do to get a hold of the magnifier, I'm not sure what code differences between Orca and LSR might be causing an issue. In addition, if I run "/usr/bin/magnifier -vz 2" by hand, it runs. If I run "/usr/bin/magnifier" with no arguments, it fails: $ /usr/bin/magnifier GTK Accessibility Module initialized (magnifier:15536): Bonobo-WARNING **: Assigning a default value to a non readable property 'source-display-screen' (magnifier:15536): Bonobo-WARNING **: Assigning a default value to a non readable property 'target-display-screen' yes yes :0.0 yes here ** Message: added event source to xfixes cursor-notify connection ** Message: added event source to damage connection ** Message: added event source to composite connection yes initial viewport 1024 768 ** Message: set source bounds to 0,0; 1024,768 The program 'magnifier' received an X Window System error. This probably reflects a bug in the program. The error was '176'. (Details: serial 2320 error_code 176 request_code 150 minor_code 11) (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.)
Created attachment 83662 [details] test case
(In reply to comment #10) > Created an attachment (id=83662) [edit] > test case > Thanks George! I still get the same COMM_FAILURE :-(. Does the test case work for you? wwalker@wwalker-laptop:~$ uname -a Linux wwalker-laptop 2.6.20-9-generic #2 SMP Mon Feb 26 03:01:44 UTC 2007 i686 GNU/Linux wwalker@wwalker-laptop:~$ gnome-about --version GNOME gnome-about 2.17.92 wwalker@wwalker-laptop:~$ python gnomemag.py Traceback (most recent call last):
+ Trace 115010
mag = bonobo.get_object(REGISTRY_IID, REGISTRY_OBJ) CORBA.COMM_FAILURE wwalker@wwalker-laptop:~\$ grep magnifier /usr/lib/bonobo/servers/GNOME_Magnifier.server type="exe" location="/usr/bin/magnifier">
But...if I change the bonobo activation file as so, things suddenly work again: wwalker@wwalker-laptop:~$ grep magnifier /usr/lib/bonobo/servers/GNOME_Magnifier.server type="exe" location="/usr/bin/magnifier -vz 2">
Works here on my old and crusty 2.16 desktop. :) [parente@pparent Desktop]$ gnome-about --version Gnome gnome-about 2.16.0 [parente@pparent Desktop]$ uname -a Linux pparent.raleigh.ibm.com 2.6.19-1.2895.fc6 #1 SMP Wed Jan 10 18:32:37 EST 2007 i686 i686 i386 GNU/Linux [parente@pparent Desktop]$ python gnomemag.py [parente@pparent Desktop]$
> Works here on my old and crusty 2.16 desktop. :) Silly questions to make sure we're both testing gnome-mag from GNOME 2.17.x, but just to make sure: 1) Which version of gnome-mag do you have? Is it of the same crust as your crusty 2.16 desktop? 2) What does the following command give you? grep magnifier /usr/lib/bonobo/servers/GNOME_Magnifier.server
> 1) Which version of gnome-mag do you have? Is it of the same crust as your > crusty 2.16 desktop? gnome-mag from svn HEAD. 0.14.10 or something. > 2) What does the following command give you? > > grep magnifier /usr/lib/bonobo/servers/GNOME_Magnifier.server type="exe" location="/usr/bin/magnifier">
OK. Very odd. Perhaps it's an X Server difference. Moving forward... Hard Code Freeze for GNOME 2.18 is Monday. Carlos and I have a date to IRC this weekend. If we cannot resolve the problem so that Carlos can have a fixed tarball by Monday, I'd like to request that the patch for this bug be pulled and that "-vz 2" be restored and a new gnome-mag tarball for GNOME 2.18 is released by Monday. Then, for GNOME 2.19, revisit this patch. My justification for this request is that this patch was addressing an annoying cosmetic problem that happens when the magnifier first starts. The effect of the patch is that while it may have eliminated the cosmetic annoyance on one platform (FC 6), it seems to have caused breakage on another platform (Ubuntu). Sound OK?
BTW, the problem seems to be related to the XFIXES extension. Here's the relevant snippet of "xdpyinfo -queryExtensions" on my machine that is showing the problem: number of extensions: 29 BIG-REQUESTS (opcode: 130) Composite (opcode: 154) DAMAGE (opcode: 155, base event: 117, base error: 185) DPMS (opcode: 137) Extended-Visual-Information (opcode: 139) GLX (opcode: 142, base event: 77, base error: 153) MIT-SCREEN-SAVER (opcode: 132, base event: 67) MIT-SHM (opcode: 143, base event: 94, base error: 166) MIT-SUNDRY-NONSTANDARD (opcode: 129) RANDR (opcode: 153, base event: 115, base error: 182) RENDER (opcode: 152, base error: 177) SECURITY (opcode: 149, base event: 112, base error: 174) SGI-GLX (opcode: 142, base event: 77, base error: 153) SHAPE (opcode: 128, base event: 64) SYNC (opcode: 131, base event: 65, base error: 128) TOG-CUP (opcode: 138) X-Resource (opcode: 141) XAccessControlExtension (opcode: 148) XC-APPGROUP (opcode: 147, base error: 173) XC-MISC (opcode: 133) XFIXES (opcode: 150, base event: 113, base error: 176) XFree86-Bigfont (opcode: 151) XFree86-DGA (opcode: 136, base event: 68, base error: 145) XFree86-Misc (opcode: 135, base error: 137) XFree86-VidModeExtension (opcode: 134, base error: 130) XInputExtension (opcode: 144, base event: 95, base error: 167) XKEYBOARD (opcode: 146, base event: 111, base error: 172) XTEST (opcode: 145) XVideo (opcode: 140, base event: 75, base error: 150)
More investigation seems to say that the block of code around line 505 in magnifier-main.c seems to make the difference between success and crashing. if (global_options.vertical_split || global_options.horizontal_split || global_options.fullscreen) { ... }
Created attachment 83714 [details] [review] Patch to prevent magnifier from quitting when run with no arguments Here's a one line patch Carlos and I came up with last night. It still doesn't fix all the problems we're seeing with magnification, but it does prevent the magnifier from quitting when it is run with no arguments.
Created attachment 83780 [details] [review] disable COMPOSITE by default putting --ignore-composite in GNOME_Magnifier.server I had commented in add an --enable-composite option to the 'configure' script, but after talking with Willie we conclude that is best the user that want to play with it be able to enable COMPOSITE without having to re-compile gnome-mag. The COMPOSITE support is being disable due performance reasons and due some problems in the interface. For one of these problems, see: http://bugs.freedesktop.org/show_bug.cgi?id=8871 This also occur in Firefox.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.