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