XtDisplayToApplicationContext fails with "Error: Couldn't find per display information"
Eirik Byrkjeflot Anonsen
eirik at opera.com
Wed Feb 4 01:51:51 PST 2009
Glynn Clements <glynn at gclements.plus.com> writes:
> Tristan Schmelcher wrote:
>> Hello all. Sorry if this is not the right place to send this, but I'm
>> developing a plugin for Firefox on Linux and I've run up against a
>> roadblock. In my plugin I'm being passed a pointer to an X "Display" struct
>> (in NPP_SetWindow, for those of you that know NPAPI) and I'm calling
>> XtDisplayToApplicationContext on it to get an app context to use in various
>> Xt calls. Now on most systems this works fine--e.g., Ubuntu Dapper 32-bit
>> with FF2 and Intrepid 32-bit with FF3 both work flawlessly. However, when I
>> build a 64-bit version and try it on Ubuntu Hardy 64-bit with FF3, it
>> doesn't work. When it enters XtDisplayToApplicationContext, I get "Error:
>> Couldn't find per display information" on the console and the program exits.
>> Does anyone know what could be causing this function to fail? I searched the
>> web but without luck.
> AFAIK, the display must have been "registered" with Xt via
> XtDisplayInitialize(). With a conventional Xt-based application, this
> is done by e.g. XtAppInitialize().
> Firefox isn't an Xt application, so I'm a bit surprised that it works
> at all. However, digging deeper I see that libxul.so uses Xt:
This is a requirement in the netscape plug-in api. It passes a window
that is documented to be an XmDrawingArea to the plug-in. However,
most browsers ignore that and uses a plain Xt window instead.
Obviously, the plug-in itself needs some way of accessing the window
and receiving events. Painting can be done with plain X, but in order
to receive events, the plug-in must register with the browser's main
loop. So the only reasonable thing to do is to use Xt. (Yes, the
netscape plug-in api is broken by design. The windowless style is
slightly less broken, though.)
More information about the xorg