[BRLTTY] BRLTTY blocked on console while Orca is running on Wayland

[Samuel Thibault]

Hello,

Elias Oltmanns, le sam. 20 déc. 2025 19:50:05 +0100, a ecrit:
> On 2025-12-20 at 01:00:18 (+0100), Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
> > Hello,
> > Elias Oltmanns, le ven. 19 déc. 2025 18:51:31 +0100, a ecrit:
> >> On 2025-12-19 at 14:44:27 (+0100), Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
> >> > Hello,
> >> > Elias Oltmanns, le ven. 19 déc. 2025 14:32:14 +0100, a ecrit:
> >> >> - Braille device responds to Orca now (as expected).
> >> >> - Switch to tty2 in text mode.
> >> >> - The braille device still shows Orcas output
> >> > 
> >> > It looks like orca doesn't manage to properly claim only the VT of the
> >> > wayland session.
> >> > 
> >> > When running inside a terminal, do you have these environment variables
> >> > set:
> >> > 
> >> > XDG_VTNR 
> >> >
> >> When I launch „terminal“ from within my GNOME session, XDG_VTNR is not
> >> set anymore,
> > 
> > Ok, so that's why.
> > 
> > Is your system using systemd? Normally it's set in the VT sessions.
> 
> Yes, systemd rules them all. Still, XDG_VTNR is not set when I start
> terminal under Wayland.
> By the way, after login on the text console on tty2, XDG_VTNR is set.

Bleh... Why did that get dropped for graphical sessions... That's really
not orca's fault, but systemd somehow not actually telling the session
where it's actually living.

How is your wayland session started? Are you using e.g. lightdm, gdm,
something else to log in graphically, or just startx?

> Once I attach to my tmux session (or start a new one), however, XDG_VTNR
> is not set there either.

Yes, that part is expected: since you can attach to your tmux from
anywhere, XDG_VTNR is meaningless.

> >> > Please also post the content of
> >> > 
> >> > /proc/1234/environ
> >> > 
> >> > where you replace 1234 with the pid of orca, so we get to know what
> >> > exactly orca has as environment variables.
> >> 
> >> This file appears to be empty since cat produces no output.
> > 
> > Had you replaced 1234 with the pid of orca? It's really not supposed to
> > be empty.
> 
> Yes, I did replace it. Since then, I have started using the following
> command for testing:
> 
> tr '\0' '\n' < /proc/`pidof orca`/environ
> 
> Strangely enough, this results in a lot of empty lines and nothing else.

Uh, happens here as well...

If people remove more and more debugging information from /proc, how are
we supposed to fix bugs?...

> Then I tried the following:
> $ tr '\0' '\n' < /proc/`pidof gnome-session-init-worker`/environ | grep XDG_VTNR
> XDG_VTNR=1

So somehow gnome does get the variable...

> $ tr '\0' '\n' < /proc/`pidof gnome-shell`/environ | grep XDG_VTNR

... but doesn't pass it along?

It'd be useful to see your 'ps xf' with orca to check how processes are
getting started, and thus see where the variable is getting dropped.

> So, gnome-shell does not have XDG_VTNR in its environment either.

Does that file for gnome-shell contain something else than empty lines?

Samuel