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

[Samuel Thibault]

Hello,

Alexander Epaneshnikov, le sam. 17 oct. 2026 22:13:26 +0300, a ecrit:
> Sorry about that. I'm adding qemu-devel and the BRLTTY list now, and
> quoting my original message in full below for the lists.

Thanks, that will help to get advice from everybody and agree on things.

> > Alexander Epaneshnikov, le sam. 17 oct. 2026 15:23:14 +0300, a ecrit:
> > > For serial ports it detects the display by sending PROTOCOL_ONOFF (0x15) to turn the protocol off and then on, then waits for the cell count (0x01) and the device identity (0x84).

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?

> > > 2. Sharing the display between the host and the guest.
> > >
> > > My prototype adds a small grab notifier in ui/input.c. input-linux fires it when the grab toggles.

That part needs to be discussed with qemu.

> baum then changes its BrlAPI client priority (BRLAPI_PARAM_CLIENT_PRIORITY, local): 80 while the guest holds the grab, which is above Orca's 50 and the 70 it uses in flat review, and 0 (disabled) when the grab is released.

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?

> Under libvirt, QEMU has no controlling tty, so I also set CONTROLVT in the environment.

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

> BRLTTY then switches between the two clients on the same tty without reconnecting, and each side's last content comes back straight away. 

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

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. That way everything will go just smoothly.

> > > - Is client priority the right BrlAPI mechanism for this, or would you rather do it another way?
> > > - Should it be opt-in, for example a chardev option?
> > > - Should other grab sources (SDL, GTK) report to the same notifier, or should it stay limited to input-linux?

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

Samuel