Dear Maintainer,

when starting Gnome on Xorg it hangs with a black screen, the mouse cursor is
displayed, but cannot be moved.

As reason I could identify (with ps) the start of /usr/bin/xbrlapi.

how I can reproduce the issue
- start gdm3 and login to Gnome on Xorg
- the screen switch to black
- switch to a tty, e.g. CTRL-ALT-4
- run: killall xbrlapi
- switch back to the GUI, CTRL-ALT-1
- enter the user password
- Gnome on Xorg is running

how I workaround the issue
- comment out the upmost if-statement in /etc/X11/Xsession.d/90xbrlapi

what I have done to exclude other reasons
- it can be reproduced with a new created user
- it can be reproduced with a Xfce session

cheers
Frank

Hello,

SubOptimal via Pkg-a11y-devel, le sam. 09 nov. 2024 11:53:06 +0100, a ecrit:

I can't reproduce the issue. I tried to install a sid system from
scratch with the gnome desktop. xbrlapi does get started, but no hanging
issue.

Does that xbrlapi process belong to the root user or your user?

Do you have the brltty package installed?

Could you redirect std output and error output of the xbrlapi command to
some file so we get more information? Adding the -v option might also be
useful.

Samuel

Samuel

Samuel Thibault, le dim. 10 nov. 2024 11:48:03 +0100, a ecrit:

Hi Samuel,

sorry for the long delay.

Samuel Thibault <sthibault@debian.org> wrote:

The process belongs to my user.

It was not. After installing the package brltty it seems to solve the
issue.

WHat I have done.

- file /etc/X11/Xsession.d/90xbrlapi was reverted to the version
  installed by package xbrlapi
- package brltty was installed
- no other changes were applied
- X11 sessions do work again

In /etc/X11/Xsession.d/90xbrlapi I added the redirects as

```
if [ -x "${xbrlapi}" ]; then
  "${xbrlapi}" > /tmp/xbrlapi.stdout 2> /tmp/xbrlapi.stderr
  if "${xbrlapi}" 2>/dev/null ; then
```

Without brltty package installed the /tmp/xbrlapi.* files both are
empty after trying to start X11 Gnome.

With brltty package installed the /tmp/xbrlapi.stdout contains

```
xbrlapi: didn't grab window 0x00000001 but got focus
```

A possible reason how it might have come to that situation, xbrlapi was
installed as recommendation for orca.

- gnome-core depends on orca
- orca recommends xbrlapi and suggests brltty
- xbrlapi neither recommends or suggests brltty

cheers
Frank
--

Hello,

Frank Dietrich, le dim. 01 déc. 2024 17:07:28 +0100, a ecrit:

No problem, better some reply after some time rather than none :)

Ok, so it's really about xbrlapi trying to connect to brltty but not
realizing that it's not there.

Uh. Could you try to install strace and use

so we get to know exactly what it tries to do when trying to connect to
brltty? Normally we would get something like

connect(3, {sa_family=AF_INET, sin_port=htons(4101), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connexion refusée)

Do you perhaps have a daemon listening on port 4101? (there's really not
supposed to be any, it's a port reserved at Iana)

Yes, that is expected. And normally xbrlapi without brltty is harmless.

Thanks,
Samuel

Hello,

I appear to have reproduced this issue on Kali rolling with a newer xbrlapi/brltty package version than the original report.

Environment:

- Distribution: Kali rolling
- Desktop environment: XFCE
- Display manager: LightDM
- Session type: X11
- xbrlapi package version before workaround: 6.9.1-1
- Package state before workaround: xbrlapi installed, brltty not installed
- Relevant Xsession script: /etc/X11/Xsession.d/90xbrlapi

Symptom:

The system reached graphical.target quickly, but after graphical login the desktop appeared to stall before XFCE’s core desktop clients launched.

Boot timing was not the issue:

  Startup finished in 3.151s (kernel) + 5.686s (userspace) = 8.838s
  graphical.target reached after 5.685s in userspace

Before removing xbrlapi, the graphical login/session timeline showed:

  12:18:12  lightdm --session-child started
  12:18:16  gnome-keyring-daemon started
  12:18:16  xfce4-session started
  12:20:31  xfwm4 started
  12:20:31  xfsettingsd started
  12:20:31  xfce4-panel started
  12:20:31  xfdesktop started

So xfce4-session started, but the core XFCE desktop clients did not launch until approximately 135 seconds later.

After purging xbrlapi and rebooting, the same session startup path became fast:

  12:33:00  lightdm --session-child started
  12:33:03  gnome-keyring-daemon started
  12:33:03  xfce4-session started
  12:33:04  xfwm4 started
  12:33:04  xfsettingsd started
  12:33:04  xfce4-panel started
  12:33:04  xfdesktop started

So the delay collapsed from approximately 135 seconds to approximately 1 second.

This appears consistent with the earlier finding in this bug: xbrlapi can block the Xsession startup path when brltty is absent.

Additional details:

- /etc/X11/Xsession.d/90xbrlapi was present before the workaround.
- The xbrlapi package was installed, but brltty was not.
- Purging xbrlapi removed the startup delay.
- The issue was observed with XFCE under LightDM/X11 rather than GNOME/GDM, but the symptom and workaround appear to match this bug closely.

I am adding this as a data point because the issue appears to still affect newer package versions, at least in Kali rolling, which imports the Debian brltty/xbrlapi packaging.

Regards,
earthenvessel

Hello,

earth3n7essel@gmail.com, le jeu. 04 juin 2026 10:35:30 -0700, a ecrit:

As mentioned previously in the bug tracker, I am not able to reproduce
the issue.

When brltty is not installed, xbrlapi should be simply getting
ECONNREFUSED and immediately exit. Apparently that's not happening so
for some reason, which is what needs to be determined, and I can't do
that since I can't reproduce the issue.

As mentioned previously, using strace would help:

“
Could you try to install strace and use

so we get to know exactly what it tries to do when trying to connect to
brltty?
”

and it was mentioned that perhaps some daemon could be listening on port
4101?

sudo netstat -tanp | grep 4101

could tell what could be listening there.

Perhaps there could be a firewalling thing in the situation

Samuel

Hello,

I was able to reproduce the Xorg login delay again after reboot and captured some supporting artifacts.

System/context:

- Distro/session: Kali rolling, XFCE via LightDM/Xorg
- Kernel: 6.19.14+kali-amd64
- xbrlapi: 6.9.1-1 installed
- brltty: not installed
- strace: 6.18+ds-2 installed
- Port 4101: no TCP listener/connection detected after login

Observed behavior:

During login, the X session was delayed again before the desktop fully appeared. The attached archive includes a filtered current-boot journal, the current xsession-errors file, and an instrumented xbrlapi trace from the /etc/X11/Xsession.d/90xbrlapi path.

The trace directory in the attached archive is:

  xbrlapi-repro-20260608-144913/xbrlapi-trace-20260608-144630-pid3513/

I sanitized the archive before attaching it, redacting personal/local identifiers while preserving the diagnostic details.

Regards,
earthenvessel

Hello,

earth3n7essel@gmail.com, le lun. 08 juin 2026 12:45:35 -0700, a ecrit:

Ok.

Thanks!

14:46:30.315375 connect(3, {sa_family=AF_INET6, sin6_port=htons(4101), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "IPV6_REDACTED", &sin6_addr), sin6_scope_id=0}, 28) = -1 ETIMEDOUT (Connection timed out) <135.074947>
14:48:45.390569 close(3)                = 0 <0.000183>

So that is the culprit, it's waiting for two minutes rather than getting
an immediate ECONNREFUSED. Do you happen to have a firewall that could
be eating the packets?

I'd rather not disable the TCP attempt since that's useful for
ssh-forwarded connections. I guess we could at least reduce the timeout
since on localhost the connection should be immediate.

Samuel

Samuel Thibault, le lun. 08 juin 2026 21:54:13 +0200, a ecrit:

Could you try to rebuild the brltty package with the attached patch?

Samuel

Hello Samuel,

I found the explanation for why ::1 was timing out on this system.

During unrelated troubleshooting a couple of weeks ago, I had disabled IPv6 on this machine, including on the loopback interface. So the system was in this state:

  net.ipv6.conf.all.disable_ipv6 = 1
  net.ipv6.conf.default.disable_ipv6 = 1
  net.ipv6.conf.lo.disable_ipv6 = 1

However, /etc/hosts still contained the normal IPv6 localhost entry for ::1.

That appears to be what produced the timeout you saw in the strace: localhost IPv6 was still advertised via /etc/hosts, but IPv6 loopback was not usable on lo.

I tested that directly with a small Python socket test connecting to port 4101 on both 127.0.0.1 and ::1. With IPv6 still disabled on loopback, the result was:

  127.0.0.1 ConnectionRefusedError [Errno 111] Connection refused after 0.0 s
  ::1 TimeoutError timed out after 3.003 s

Then I re-enabled IPv6 on the loopback interface:

  sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=0

After that, the same Python test failed immediately for both IPv4 and IPv6:

  127.0.0.1 ConnectionRefusedError [Errno 111] Connection refused after 0.0 s
  ::1 ConnectionRefusedError [Errno 111] Connection refused after 0.0 s

I also tested this with xbrlapi itself:

1. Reinstalled xbrlapi while IPv6 loopback was still disabled.
2. Rebooted and logged in.
3. Confirmed that the login delay returned, around 135 seconds.
4. Re-enabled IPv6 loopback.
5. Rebooted and logged in again.
6. Confirmed that the login delay disappeared.

So the reproducible condition seems to be:

1. brltty is absent / not listening on port 4101.
2. xbrlapi is installed and runs during session startup.
3. /etc/hosts contains the normal ::1 localhost entry.
4. IPv6 is disabled on lo, so ::1 is advertised but not actually usable.
5. xbrlapi gets ECONNREFUSED immediately from 127.0.0.1:4101, but the ::1:4101 attempt waits for the TCP timeout.

So your firewall suspicion was pointing in the right direction: something local was making the IPv6 localhost connection get swallowed instead of refused cleanly. In this case it appears to have been disabled IPv6 loopback rather than a firewall rule.

Regards,
earthenvessel

Hello,

I can reproduce this issue on Linux Mint 22.3 (Ubuntu 24.04 Noble base)
with LightDM and Cinnamon on X11.

The symptom was a black screen with a movable mouse cursor after entering
the password in LightDM. The Cinnamon desktop appeared only after
approximately 2-3 minutes.

The issue was reproducible with a newly-created user account, so it was
not caused by per-user Cinnamon configuration.

I also tested different kernels and graphics configurations. These did
not affect the delay.

I instrumented the LightDM session startup and found that the session was
blocked waiting for xbrlapi.

During the delay the process tree remained:

/bin/bash /usr/sbin/lightdm-session cinnamon-session-cinnamon
`- /bin/xbrlapi

For example, after 132 seconds:

USER PID PPID ELAPSED STAT WCHAN CMD
bobsyan 1407 1207 132 Ss do_wait /bin/bash /usr/sbin/lightdm-session cinnamon-session-cinnamon
bobsyan 1479 1407 132 S wait_woken /bin/xbrlapi

At approximately 134 seconds the same state was still present.

Immediately afterwards xbrlapi disappeared and PID 1407 exec'd:

/usr/lib/x86_64-linux-gnu/cinnamon-session-binary --session cinnamon

Cinnamon startup then continued.

Disabling the xbrlapi Xsession hook:

sudo mv /etc/X11/Xsession.d/90xbrlapi \
/etc/X11/Xsession.d/90xbrlapi.disabled

completely removed the long login delay.

Relevant BRLTTY packages on the system:

brltty 6.6-4ubuntu5
libbrlapi0.8 6.6-4ubuntu5

Another potentially important observation is the behaviour of TCP
connections to the BRLAPI port on loopback.

IPv4 fails immediately, as expected when nothing is listening:

127.0.0.1: ConnectionRefusedError: [Errno 111] Connection refused, 0.000 s

IPv6, however, does not return ECONNREFUSED and instead times out:

::1: TimeoutError: timed out, 5.004 s

IPv6 itself is enabled:

net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

There is no ipv6.disable kernel parameter:

BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic
root=UUID=...
ro quiet splash

This suggests that xbrlapi may attempt the IPv6 loopback connection first
and remain blocked by the TCP connect timeout instead of failing quickly.

In this case, xbrlapi being started synchronously from the Xsession hook
causes the entire graphical desktop session to be delayed for roughly
two minutes.

Environment:

Distribution: Linux Mint 22.3 "Zena"
Ubuntu base: 24.04 Noble
Desktop: Cinnamon 6.6.9
Display manager: LightDM
Session type: X11
Kernel: 7.0.0-31-generic
BRLTTY: 6.6-4ubuntu5
libbrlapi0.8: 6.6-4ubuntu5

The issue was confirmed by monitoring the LightDM process tree once per
second. I have attached the complete monitoring log.

The workaround of disabling /etc/X11/Xsession.d/90xbrlapi has been
retested and the login delay disappears.

Please let me know if additional traces (strace of xbrlapi, nftables
rules, LightDM logs, etc.) would be useful.

Regards,Andre

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

We believe that the bug you reported is fixed in the latest version of
brltty, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1087173@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Samuel Thibault <sthibault@debian.org> (supplier of updated brltty package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 13 Sep 2026 16:40:00 +0200
Source: brltty
Architecture: source
Version: 6.9.1+repack-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Accessibility Team <pkg-a11y-devel@alioth-lists.debian.net>
Changed-By: Samuel Thibault <sthibault@debian.org>
Closes: 1087173 1142226 1142305 1142742 1145344
Changes:
 brltty (6.9.1+repack-2) unstable; urgency=medium
 .
   [ Samuel Thibault ]
   * control: Drop old policykit-1 dependency.
   * po/fr.po: Update translation.
   * patches/git-localhost-timeout: Make connections to localhost timeout after
     0.1s (Closes: Bug#1087173)
 .
   [ Américo Monteiro ]
   * po/pt.po: Update translation (Closes: Bug#1142226)
 .
   [ Helge Kreutzmann ]
   * po/de.po: Update translation (Closes: Bug#1142305)
 .
   [ Carles Pina i Estany ]
   * po/ca.po: Update translation
 .
   [ Paulo Henrique de Lima Santana ]
   * po/pt_BR.po: Update translation (Closes: Bug#1142742)
 .
   [ Hecker Cilbir ]
   * po/tr.po: Update translation (Closes: Bug#1145344)
Checksums-Sha1:
 30c5caa0517cb47c628c6f8c9cf5294434d17be6 3434 brltty_6.9.1+repack-2.dsc
 5948563ed94758d0b13f07d9575a35ad4b7bad30 43180 brltty_6.9.1+repack-2.debian.tar.xz
 1dda384ddc3f4d3aed2d77df70a6d49fb18ec3ae 17654 brltty_6.9.1+repack-2_source.buildinfo
Checksums-Sha256:
 f7fdd39fc52de53384d0ec874c72622640325b78ed9cfeb79b746672eda97aad 3434 brltty_6.9.1+repack-2.dsc
 4d4bfdbcd3fd749371f87e2f4be1f7eb9992aa990cc130ef1a49271762c98d1d 43180 brltty_6.9.1+repack-2.debian.tar.xz
 e772372f225a8679f002c6c5a90b6367c590436f129510aa2fd1a3f16cd971ba 17654 brltty_6.9.1+repack-2_source.buildinfo
Files:
 5b5fa6d2cd69155a97463367bdc76e1b 3434 admin optional brltty_6.9.1+repack-2.dsc
 a8744a8f94c21ddba163f29250860317 43180 admin optional brltty_6.9.1+repack-2.debian.tar.xz
 925c58e73400905a594bf7689127eaa6 17654 admin optional brltty_6.9.1+repack-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEDHkkXhaQVdLZstA3O2TU75284AwFAmqmteYACgkQO2TU7528
4Awz0w/9EXwOcGdUlx7i2mlFvmbtL0LQn+pGADfp+Z6gMXIqi2XN7FYOJi017CG2
e+oT3w12uS0iAdJXeRheHMGY7sruGuYBf6nMJ07zi8sbyXwXjFPSwt0F8/iuDnJk
uUXKSzJFXv/pJOeQba8dKVFxkBTAMbH5nDPQFuTS1FFp4RXKEQ9oH9uTF5anDtsd
84UalrDm207zNHyZtn7rYgVN5nL/SvKaWk3Yl+bhXtSKj1rzF+RXHK9+WP0fWbqf
68CoS1iSh+xgTiIY6zSs9PWWJB8nICmDs6Xk5Z+wXbW82fYTaEpf4BAmDfoNIGp2
yoVfE6HtY1ayIDSimBgQ2Y8qJ9PtFlmXMyqSzQrn9QRxJuz3iG9LoNar8GnC/ezC
9y7YlqlEbIur/vLCrl6astfxlTTGFCvcbggHK+ceQJBliQ8/KzH8N26R6+Gmq6Kf
DqePumhiKdX9VD9BGkRmEm6G4HecjJfhxCDMghTCwZy6D4AGzGo/QnuylKnKhuIX
2C9IcQEkhSt8q10FSj8bzg3vCEhmSxBOGmI1Hk7+3MHwZNASMd0gkHIg1yi1zWjn
KYHiyV/y0EdQPPb2nQY0c3kQT3r8vfUfaBp7Eny2E8VoHbh/ee6TuPc6UNKOqWU7
HLTwrr06gXXIJuAfVlLfIA5FWcXu9CVH1U2Xf0D9QK4bYMXw3qg=
=68sW
-----END PGP SIGNATURE-----