Re: baum: NVDA does not detect usb-braille, and following the input-linux grab

[Alexander Epaneshnikov <aarnaarn2@gmail.com>]

Hello Samuel,

On Sun, Oct 18, 2026 at 06:26:53PM +0200, Samuel Thibault wrote:
> Ah, that is a requirement of the protocol? Then we need to do that
> indeed. What is the value of the uint8_t protocol field when it
> expects to receive 0x01 and 0x84?

It is 1 (on). For serial displays, NVDA's Baum driver
(source/brailleDisplayDrivers/baum.py) first sends 0x15 with 0 to make
sure the protocol is off, then sends 0x15 with 1 twice, "in case the
display misses the first one". After that it waits for the cell count
and the device identity. According to the comment in that driver, a
real display answers only when the protocol goes from off to on. On
that transition it sends its device identity, its serial number and
its cell count, and it sends nothing if the protocol was already on.
NVDA itself only waits for the cell count and the identity.

> I'm a bit surprised by setting the priority to 0, but maybe that's
> because of your setup, which is not described enough. Are you
> running on the linux console or X, actually?

Sorry, I should have described it. The host runs GNOME on Wayland on
tty 2, with Orca using BrlAPI. BRLTTY drives a HumanWare Brailliant
BI 40X over USB.

The guest is a Windows VM started by libvirt, with a second GPU passed
through to it. My monitor is connected to both GPUs. I switch its input
by hand, or over DDC/CI when I need sighted help. QEMU itself has no
window: the display is "none", and SPICE has no listener. I am blind,
so in practice I use the guest through NVDA's speech, which comes out
through PipeWire on the host, and its braille.

> But then how do you access the VM to get keyboard/mouse access?

Through input-linux (libvirt <input type='evdev'> with grab='all').
QEMU reads the host keyboard and mouse evdev devices directly. Pressing
both Ctrl keys toggles the exclusive grab between the host and the
guest. Because there is no window, nothing gains or loses focus when I
switch, and WINDOWID cannot help.

> What are the two clients you are talking about? Is that two VMs run
> by qemu?

No, there is a single VM. The two BrlAPI clients on tty 2 are Orca on
the host and QEMU's baum chardev, which shows NVDA's output from the
guest.

> My crude guess is that you are using some sort of front-end. In that
> case, one would rather need to teach it to access brlapi itself,
> instead of the qemu backend doing it.

There is no front-end. The grab toggle happens inside QEMU's
input-linux, so QEMU is the only process that knows which side has the
keyboard. libvirt doesn't see it, and neither does anything else on
the host. That is why I thought baum should react to it directly.

About the priority 0: my intent was that, while the host has the
keyboard, the guest's output never appears on the display. That should
hold even when Orca isn't running or isn't using the display, since
BRLTTY's own view of the tty is more useful than NVDA's last content.
A low non-zero value would also work if you think that is cleaner.

> SDL/GTK do not need a grab: provided that the window id is properly
> set, brlapi already switches according to the window focus.

Thanks, that answers my third question. Then only input-linux, which
has no window, needs to report the grab.

--
Sincerely, Alexander