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

[Alexander Epaneshnikov]

On Sun, Oct 18, 2026 at 09:17:03PM +0200, Samuel Thibault wrote:
> Alexander Epaneshnikov, le dim. 18 oct. 2026 21:52:44 +0300, a ecrit:
> > On Sun, Oct 18, 2026 at 06:26:53PM +0200, Samuel Thibault wrote:
> > > 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.
> >
> > 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.
>
> So you mean that you make qemu steal keyboard presses from under your
> Wayland session? That is very peculiar... I'm really unclear this way of
> stealing the keyboard will work on the long run.

I am using evdev for it, qemu uses it, and I think evdev isn't going anywhere.

> > 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.
>
> I now understand your situation, but I don't think it is long-term
> sustainable :/

I am using this setup for I think 4 years already.

>
> > > 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.
>
> Yes, this is really a situation only for such tinkering.

Should I understand this as that you are not interested in making this feature upstream and I should carry my own downstream patches?

If so, it is totally normal, but in my defense, I think this is a useful feature, and the code is rather small for it.

> Samuel

--
Sincerely, Alexander