Re: [gdm-list] at-spi-registryd not starting automatically in gdm [was multiple at-spi...]




Francesco:

At 12:08 PM -0500 8/28/07, Brian Cameron wrote:
You mention you are using Ubuntu.  Others on Ubuntu have complained about
this problem.  Do you not see this?

  http://bugzilla.gnome.org/show_bug.cgi?id=440948

The problem does not occur on my setup. In fact, I am using gdmlogin with Assistive Technology activated without a problem on Ubuntu 7.10 due for October (it is the version under development). I am even using it under 7.10 with onboard and mousetweaks.

As I also have a partition with the current 7.04 version of Ubuntu, I tried to start gdmlogin with Assistive Technology enabled. It works also. Please, consider that I am working remotely; but I assume that it is not what is making the difference. Could it be the following?
http://bugzilla.gnome.org/show_bug.cgi?id=457998

I'm glad to hear that the Ubuntu problem reported in that bug is not
a problem for you.  Hopefully it has somehow been fixed, we have
removed some code from the dwellmouselistener that was perhaps
causing the issue (as you point out).  I never heard about any non
Ubuntu user having that problem.

I have been told that the automatic start of at-spi-registryd in ubuntu has probably been disabled on purpose because of incompatibilities with certain hardware.
This seems badly broken to me.  What incompatibilities?  Are there
bugs filed about these issues?  I assume that Ubuntu doesn't disable
starting at-spi-registryd in the user's session.  If it works okay
in the session, how does hardware issues create problems for GDM
only?

Sorry, my assertion of at-spi-registryd being probably disabled on purpose was not correct; here is what Sebastien Bacher replied to me on the ubuntu-desktop mailing list; Sebastien Bacher is the maintainer of the desktop for ubuntu:

I'm glad to hear that Sebastien is not applying patches to disable
a11y on Ubuntu.  The problem must, as he suggests, be upstream.  That
said, it seems to work okay on Solaris.

Note the code in gui/gdmcommon.c, the function gdm_common_atspi_launch
which calls pre_atspi_launch in the same file.  It assumes that
at-spi-registryd is in LIBEXECDIR.  If it is in a different location
on your system, this could cause the problem.  I don't see any other
obvious things that would make the code not work on a different
platform.  You mention it fails when you log in remotely.  If it
works when you log in locally, then perhaps the current code is
broken for the remote case.

I'd recommend inserting gdm_debug calls into this area of the code to see
what the code is doing and to print out any failure return codes, etc.
Then I'd run make and in the build tree do the following

export DOING_GDM_DEVELOPMENT=1
./gdmlogin

Setting this environment variable allows you to run the GUI programs
like gdmlogin and gdmgreeter from a logged in session for debugging
and theme development purposes.  However, the code to call
gdm_common_atspi_launch in gui/gdmlogin.c is only executed if
DOING_GDM_DEVELOPMENT is not true, so you'll need to comment
out those if-tests so it always calls the function.  Normally
you don't want it to try to start the registry daemon in this
mode because the user should already have one running if they
need it.  And it will fail to start if one is already running.
But if you run your desktop without accessibility turned off,
then you can see if running gdmlogin this way starts it.  This
might be easier than however you are testing this issue now.

Note you can also test gestures in this way if you run gdmlogin
or gdmgreeter with the GTK_MODULES environment variable set to
the value in the GDM configuration file.

Also note you can turn on debugging in the gesture modules by
setting the GDM_DEBUG_GESTURES=1 environment variable or turn
it on in the GDM configuration.

Moreover, the fact that at-spi-registryd starts automatically in Ubuntu 7.04 could be seen as a confirmation of that fact; I just checked it. (I am using normally Ubuntu 7.10)

So you are saying it worked in 7.04 but doesn't in 7.10.  We changed
the way GDM starts at-spi-registryd in GDM 2.17.1, and a similar
change went into gnome-session.  The "new" way of launching
at-spi-registryd hasn't changed significantly since then.  Does
at-spi-registryd require the gdm user have a writable $HOME
directory now or something?  This is a common reason some
programs will fail to startup if you try to run them from GDM.

Apart from the developer of mousetweaks, I have not got another confirmation yet, that the problem also occurs on other computers running ubuntu...

I have searched syslog for an error regarding at-spi-registryd; but could not find anything. But that may also be due because I don't really know what to look for. (I have debug enabled in gdm)

Should at-spi-registryd be started by gdm or by gdmlogin?

Yes,

If you have some ideas about how to narrow down the problem, please don't hesitate. I would say to first check whether gdm/gdmlogin tries to start at-spi-registryd...

I'd follow by debug suggestions above to find out why GDM is
failing to start it.

I will file a bug against gdm in Ubuntu shortly.

Thanks.


Francesco

PS: Meanwhile, I suspect the XEVIE error that I mentioned in a previous email is due to the fact that I tried to start it with a terminal remotely through X and my local X server does not offer the necessary lib. (at-spi-registryd does start automatically in the gnome session, and also by a dwell gesture in the gdm session)

So perhaps you are only saying that at-spi-registryd doesn't startup
for remote sessions?  If a dwell gesture to start GOK, orca, or
gnopernicus works on a local X server, then the existing logic
probably just doesn't work in a remote situation.  I don't see
any code disabling the startup of at-spi-registryd in a remote
case.

Brian




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]