After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 701378 - a11y init does compile-time X check, so tries to use X under Wayland
a11y init does compile-time X check, so tries to use X under Wayland
Status: RESOLVED FIXED
Product: at-spi
Classification: Platform
Component: at-spi2-core
unspecified
Other Linux
: Low minor
: ---
Assigned To: Li Yuan
At-spi maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-05-31 16:46 UTC by Ross Burton
Modified: 2013-08-09 16:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Reorder address lookup to prefer D-BUS to X11 (1005 bytes, patch)
2013-07-24 17:39 UTC, Rob Bradford
none Details | Review

Description Ross Burton 2013-05-31 16:46:23 UTC
I've built GTK+ 3.8.2 with X11 and Wayland backends.

Running under Wayland results in it defaulting to use the X11 backend, which seems odd as I thought it could deduce I wanted to use Wayland from the presence of WAYLAND_DISPLAY and not DISPLAY.  Anyway, I set GDK_BACKEND=wayland and run gtk3-demo:

$ gtk3-demo
** (gtk3-demo:1028): WARNING **: Could not open X display

This isn't fatal but it's certainly unexpected.
Comment 1 Rob Bradford 2013-06-03 09:16:00 UTC
Would be good to attach gdb to find where it coming from - could be atk or an input method.

Since 3.8 branched changes have been made to the way that backends are initialised (using GInitable now.) Those changes would probably be too much to backport since as you say this error is not fatal.
Comment 2 Ross Burton 2013-07-03 15:29:23 UTC
As I'm too lazy to copy the gdb output via SSH, you'll have to make do with this transcription:

g_logv()
atspi_get_a11y_bus() from libatspi.so.0
atk_bridge_adaptor_init() from libatk-bridge-2.0.so.0
[...]
gtk_init() from libgtk-2.so.0
Comment 3 Ross Burton 2013-07-03 15:42:04 UTC
Looks like gtk/a11y/gail.c needs to stop doing compile-time "is this X11" checks, and do runtime checks instead.
Comment 4 Ross Burton 2013-07-03 15:52:57 UTC
Retitled.  The current situation as I understand it:

My GTK+ is built with both Wayland and X11 backends.  The a11y code in gtk/a11y/gail.c guards X11-specific code with compile-time checks, so they run under Wayland.  These compile-time checks should be runtime checks instead.

This isn't a two minute patch as the relevant piece of code runs *before* the display is opened, so simply doing a type check on the default display isn't going to work as (iirc) it doesn't exist yet.
Comment 5 Rob Bradford 2013-07-03 16:34:00 UTC
The warning is harmless and has no impact on the GTK side of things.

In term of a11y under the latest versions of the code: get_accessibility_bus_address_x11 and _dbus get called so although you will get a warning it will still identify the peer to connect to.

I think we can safely "ignore" this issue until we come about solving the a11y problem for wayland
Comment 6 Ross Burton 2013-07-03 18:13:20 UTC
I wonder if we can exchange the _x11 and _dbus function ordering so dbus happens and then falling back to X11?
Comment 7 Matthias Clasen 2013-07-03 19:11:31 UTC
sounds like a reasonable idea
Comment 8 Rob Bradford 2013-07-24 17:39:42 UTC
Created attachment 250058 [details] [review]
Reorder address lookup to prefer D-BUS to X11

This will prevent an unhelpful warning message when running under
Wayland.
Comment 9 Mike Gorse 2013-08-08 16:31:41 UTC
I'd rather not switch the order late in the cycle; iirc checking D-Bus first would cause problems for administrative apps running as root with a different session bus than the user that started the session.

Anyway, I'm hoping that commit 725b58 will fix this. Previously, AT-SPI hard-coded a default display of :0 if DISPLAY (or AT_SPI_DISPLAY) were not set, but doing this seems pointless, so now we should just not query X if neither variable is set.

AT-SPI is currently not fully funcitonal without X, but hopefully now it will at least not try to call it.
Comment 10 Rob Bradford 2013-08-09 16:13:06 UTC
Sounds good - we'll still get the warning running under Weston running under X since DISPLAY will be set; but when running directly on DRM that won't happen.