1. 24 Sep, 2020 1 commit
    • Michael Catanzaro's avatar
      Don't use dbus-broker if not running under systemd · 260a4414
      Michael Catanzaro authored
      Since gdm@febeb9a9, gdm no longer runs a systemd user session, because
      gdm supports multiseat but systemd only allows one graphical session per
      user. Since gdm currently runs as the gdm user, that means we cannot use
      systemd there. Benjamin Berg says we could fix that by changing gdm to
      use temporary users for each seat, but that would be a lot of work.
      
      Meanwhile, dbus-broker relies on systemd to autostart D-Bus services. So
      if we are not running a systemd user session, nothing gets autostarted
      in response to D-Bus calls. That means orca never gets any response to
      its method calls to org.a11y.atspi.Registry, and we wind up with no
      accessibility on the gnome-shell login screen.
      
      Fix this by implementing Benjamin's suggested check to see if we are
      running under systemd before using dbus-broker. So now we will use
      dbus-daemon on the login screen, but we will still use dbus-broker for
      the user session (except in distros that still prefer dbus-daemon...
      which is actually the default configuration). libsystemd is added as a
      build dependency whenever built with dbus-broker support, which should
      be uncontroversial because it won't work without systemd.
      
      I expect dbus-daemon is going to live alongside dbus-broker for a long
      time, because it seems very hard for us to migrate fully.
      
      Big thanks to Benjamin Berg for discovering the problem and suggesting
      this solution.
      
      Fixes #25
      260a4414
  2. 27 Feb, 2020 1 commit
    • Mike Gorse's avatar
      bus-launcher: Use async callback for RegisterClient · 47496e0f
      Mike Gorse authored
      This should make the process more robust, in combination with setting the
      timeout to G_MAXINT, rather than -1, which effectively defaults to 25
      seconds. Otherwise, it is possible for the session manager to be
      unresponsive, perhaps waiting for a synchronous call of its own to time out,
      and then the session manager will eventually process the RegisterClient, but
      at-spi-bus-launcher will have timed out, meaning that we successfully register
      with the session manager but don't ever set up our signal handler, meaning
      that, later, the session manager sends a QueryEndSession to us, but we don't
      see it.
      
      https://bugzilla.opensuse.org/show_bug.cgi?id=1154582
      47496e0f
  3. 06 Sep, 2019 3 commits
  4. 28 Aug, 2019 1 commit
  5. 27 Aug, 2019 1 commit
  6. 21 May, 2019 1 commit
    • Carlos Garnacho's avatar
      Resort to WAYLAND_DISPLAY checks to avoid X11 connections · b68e60b7
      Carlos Garnacho authored
      Same reasoning applies (Opening and closing X11 displays may be from
      ineffective to harmful there), but the XDG_SESSION_TYPE check breaks
      for startx.
      
      Explicitly check that DISPLAY is present but WAYLAND_DISPLAY is not,
      in order to avoid this behavior.
      
      Pointed out at
      !12
      b68e60b7
  7. 06 May, 2019 2 commits
    • Carlos Garnacho's avatar
      Do not rely on getenv("DISPLAY")!=NULL to assume it is a X11 environment · 3bb82072
      Carlos Garnacho authored
      Change/add checks around the AT_SPI_BUS root window property handling so it
      is only done if the session is a real X11 one.
      
      These checks used to work on wayland sessions, as there still is a X server
      to poke, it's strange to use as a side channel but that's about it. However
      in the future mutter will start Xwayland on demand, the DISPLAY environment
      variable will definitely exist so checking for it is definitely not
      sufficient, and opening the display will unintendedly spawn Xwayland.
      
      It is debatable that this should happen in Wayland sessions at all, so let
      the org.a11y.Bus fallbacks take over.
      3bb82072
    • Carlos Garnacho's avatar
      bus-launch: Do not poke X11 to check at-spi-bus-launcher is running · 25f1cc6c
      Carlos Garnacho authored
      The already_running() check first gets the AT_SPI_BUS root window property,
      then tries to open it to check if it exists. For it to exist though there
      must be another at-spi-bus-launcher process around with the org.a11y.Bus
      name.
      
      It seems we can just defer the uniqueness check to g_bus_own_name(), as
      we will get the "name lost" callback right after failing to acquire the
      unique name. Doing it this way works for both x11 and non-x11, and avoids
      assumptions on what the current windowing actually is.
      25f1cc6c
  8. 05 Oct, 2018 1 commit
  9. 10 Aug, 2018 1 commit
  10. 17 May, 2018 2 commits
  11. 13 May, 2018 1 commit
    • Tom Gundersen's avatar
      bus-launch: add dbus-broker support · d7f47c99
      Tom Gundersen authored
      Both dbus-daemon and dbus-broker are now optional at compile-time, though
      at least one must be configured. A new configuration option is introduce in
      order to select the default implementation attempted at runtime. The other
      implementation will function as a fall-back (in case support for both are
      compiled in). If no default is selected, dbus-daemon remains the default as
      before.
      
      Unlike dbus-daemon, dbus-broker requires at-spi-bus-launch to create the
      listening socket and pass it in, rather than having the bus do that and send
      back the address. For now we follow what dbus-daemon does, and create a socket
      in the abstract namespace, though it might be more suitable to create a socket
      in $XDG_RUNTIME_DIR.
      
      The only difference users should observe is that daemons are no longer spawned
      by the bus implementation, but spawned and managed by the systemd user instance,
      though this should not lead to a difference in behavior. In particular this
      applies to `org.a11y.atspi.Registry`.
      
      For non-linux and non-systemd systems, dbus-daemon should continue to be used.
      
      [v2:
         - drop the --verbose switch, which is no longer supported
         - make dbus-daemon optional too
         - allow the default implementation to be selected]
      Signed-off-by: default avatarTom Gundersen <teg@jklm.no>
      d7f47c99
  12. 04 Dec, 2017 1 commit
  13. 26 May, 2017 1 commit
  14. 28 Dec, 2016 4 commits
  15. 14 Sep, 2016 1 commit
  16. 27 Jul, 2016 1 commit
  17. 14 Jul, 2016 1 commit
    • Mike Gorse's avatar
      at-spi-bus-launcher: session management fixes · 253ada97
      Mike Gorse authored
      At-spi-bus-launcher was attempting to register with gnome-session but
      typically failed because it was started before gnome-session is initialized.
      Now we check whether gnome-session is running and only attempt to register
      if it is; otherwise watch for SessionRunning and register when se wee it.
      
      Also, handle SessionOver.
      253ada97
  18. 25 Apr, 2016 1 commit
  19. 14 Mar, 2016 1 commit
    • Ikey Doherty's avatar
      Support a stateless configuration by default · 2ef00769
      Ikey Doherty authored
      Using a stateless configuration, we ship sensible defaults in our vendor-config
      file to live in the /usr/share/ filesystem, which is considered to be provided
      by the vendor, and to all intents and purposes, read-only.
      
      With this change we can fall-back to the vendor system configuration to
      always do the right thing, in the absence of a local system administrator
      configuration file in the /etc/ tree.
      
      Notably, this saves users from the potential risks and pitfalls of so called
      "three way merges" on upgrades, and offers the immediate benefit that one
      can perform a factory reset of the software, simply by removing the relevant
      file in /etc/.
      
      This change also resolves a memory leak in the launch code, where a string
      allocation was entirely unnecessary.
      Signed-off-by: default avatarIkey Doherty <michael.i.doherty@intel.com>
      2ef00769
  20. 26 Jan, 2016 3 commits
  21. 17 Feb, 2014 1 commit
  22. 15 Oct, 2013 1 commit
  23. 10 Oct, 2013 1 commit
  24. 08 Aug, 2013 1 commit
  25. 14 Sep, 2012 1 commit
  26. 13 Feb, 2012 1 commit
  27. 06 Feb, 2012 1 commit
  28. 22 Jan, 2012 1 commit
  29. 21 Jan, 2012 1 commit
  30. 21 Oct, 2011 1 commit
  31. 19 Oct, 2011 1 commit