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

[Samuel Thibault]

Alexander Epaneshnikov, le dim. 18 oct. 2026 22:26:32 +0300, a ecrit:
> 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:
> > > > 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.

evdev, sure, but stealing keyboard input from wayland while wayland is
running, will surely be frowned upon long-term.

> > > 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.

We have been using the linux console for decades. And still it is
getting removed in Fedora.

> > > > 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?

I mean that it's really not clear that qemu will be interested in
integrating code for supporting this situation.

Samuel