Cannot get Orca to work with the SDL example

[squeaktoy]

All I see is

This example has no visible GUI, and a keyboard interface:
- [Tab] switches focus between two logical buttons.
- [Space] 'presses' the button, adding static text in a live region announcing that it was pressed.
Enable Orca with [Super]+[Alt]+[S].

Orca is turned on, but it won't read anything from this window. Does anyone else have this issue? I'm using accesskit_c v0.6.2. I also tried compiling accesskit from source, which worked after modifying Cargo.toml to not use winit but unix instead. I couldn't build the C bindings though. It requires rustup for some reason, but I want to stick with my distro's toolchain. I just used the header from 0.6.2.
The way I compiled the SDL example is as follows:

gcc -laccesskit -lSDL2 -I/usr/include/SDL2 hello_world.c

CMake again refuses to compile it correctly because it cannot find accesskit despite it being on my system, hence the manual gcc invocation.

[DataTriny]

Hello @squeaktoy,

When you say:

Orca is turned on, but it won't read anything from this window.

Do you mean that you see a blank window but you can't hear anything when pressing the Tab key? Or do you mean that no window is open?

Which display system are you using? X11 or Wayland? I know that our winit example doesn't open any window under Wayland because we are not drawing anything.

If you have downloaded accesskit_c pre-built package through our GitHub releases, you should be able to compile the example with CMake, if this is not the case then there might be an issue and I'd like to see the output of the command please.

I am not sure to understand what you did to build AccessKit from source, but you won't be able to do so if you want to stick with your distribution provided Rust anyway. Building the header file requires a nightly compiler, and our build process require rustup to locate Cargo and other tools.

[squeaktoy]

So I just installed rustup and the nightly toolchain and installed the bindings, but the SDL example still doesn't work. I'm using X11. The window opens, but doesn't draw anything, and Orca cannot see the window at all. I can't do anything inside.

[DataTriny]

@squeaktoy I will need more information to diagnose the issue:

• Which AT-SPI version is installed on your system?
• Which Orca version are you running?
• Please upload Orca logs that show what is happening on your desktop while the app is running. Make sure to set the highest log level, and verify that no sensitive information have been captured.

Also note that the new live regions are not yet supported by Orca, so pressing Space won't display anything. You should hear the button names when pressing Tab though.

[squeaktoy]

at-spi2-core 2.48.3
Orca 45.1

Here is an Orca log from when I launch the sdl example and press tab and other keys.
debug-2024-01-03-18:11:34.log

[squeaktoy]

It seems I figured out the problem. As it turns out, dbus on my system was not configured properly, and one of the fallback mechanisms of dbus is to generate a session bus ID based on an X11 session. Some programs can handle this fallback fine, but it seems that AccessKit cannot handle it properly.
If anyone has this issue, you need to fix your dbus like so:

export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/`id -u`/bus"
dbus-daemon --session --address="$DBUS_SESSION_BUS_ADDRESS"

This is just an example and probably needs more work to be integrated into a .bashrc, .profile, or even as an init service.
If you use dinit, take a look at https://github.com/chimera-linux/cports/tree/master/main/dbus/
You can install their dbus-session.wrapper and install the dbus.user service and dbus should work with dinit now, instead of a broken X11 fallback mechanism.
If you don't use dinit, then you'll have to find your own way of properly setting up a dbus session daemon.

[DataTriny]

Just in case:

@zeenix Does the comment above make sense to you? Are you aware of this "X11 session ID fallback" mechanism apparently missing from zbus? FYI we are connecting to the session bus using Connection::session so nothing particular on our side.

[zeenix]

@zeenix Does the comment above make sense to you? Are you aware of this "X11 session ID fallback" mechanism apparently missing from zbus?

Not really. I looked for it in the spec but I found no mention of any such thing.

[DataTriny]

Thank you! Well it's purely a case of badly installed/configured dbus then. Nothing we can do about it.

[mwcampbell]

@zeenix Thank you for looking at this. Feel free to ignore this thread now; it's outside the scope of zbus.

We shouldn't give up this easily. @squeaktoy will not be the last developer interested in this library whose system is configured this way, and we don't want to give such developers, particularly those who are less tenacious than @squeaktoy, an excuse to give up on accessibility because they encounter an avoidable obstacle. I specifically want AccessKit to appeal to the kind of developer that hates bloat and, as a result, runs a minimal, idiosyncratic desktop environment.

That said, the X11 fallback is AT-SPI-specific, so it certainly doesn't belong in zbus. Basically, the AccessKit Unix adapter needs to get a property called AT_SPI_BUS from the X11 root window. A full implementation, in C using Xlib and gdk, is in GTK, in the gtk/a11y/gtkatspicontext.c source file, in the get_bus_address_x11 function. I'm not sure, though, if it's possible to do lazy initialization when only this fallback is available; we might need to do eager initialization in that case.

[DataTriny]

The original issue seem quite similar to this other one. If the session bus is running and the environment variables are properly propagated (so DBUS_SESSION_BUS_ADDRESS contains the session bus address), then we'll be able to connect to it and get AT-SPI bus' address eventually.

I think that the fallback mechanism you describe @mwcampbell is a separate issue. While it would have hidden the problem by avoiding the session bus entirely, it comes with major drawbacks. Unless I missed something, we would not be able to lazily initialize our tree so we would turn on accessibility for everyone. We would have to monitor X11 window properties to see when an atom containing the private bus address is attached, but I don't think we can do so. A more elegant solution would be to have the AT-SPI bus launcher expose the org.a11y.Bus service to both the session and the private bus.

But the only situation where this whole process is necessary is when you have a graphical application running as root, as the session bus would either be out of reach or not even started. Pretty much everyone agree that this should not be done though so I'm not sure it is worth adding this complexity into AccessKit.