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

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

[Alexander Epaneshnikov]

On Sat, Oct 17, 2026 at 02:24:22PM +0200, Samuel Thibault wrote:
> Hello,
>
> Please always keep some mailing list in Cc, so that I am not the only
> recipient of the mail. Writing to me only means risking falling in
> the middle of my vacations and thus not getting an answer for weeks,
> or that I just don't have the time to answer and thus you would at
> best get a terse answer, or worse, no answer at all... Conversely,
> keeping the list in Cc means avoiding all these issues completely,
> you'll involve all the community to help you, make the answers you
> get available to everyone, and even archived for web crawlers to find
> them whenever somebody has the same issue.

Sorry about that. I'm adding qemu-devel and the BRLTTY list now, and
quoting my original message in full below for the lists. If anyone else
on the lists is interested in picking this up, that would be welcome
too.

> Samuel
>
> Alexander Epaneshnikov, le sam. 17 oct. 2026 15:23:14 +0300, a ecrit:
> > Hi Samuel,
> >
> > I use a HumanWare Brailliant BI 40X with BRLTTY and Orca on the host, and a Windows guest under libvirt with NVDA. The keyboard and mouse go to the guest through input-linux with grab_all, toggled with left+right Ctrl. I wanted the braille display to follow that grab: NVDA's output while the guest has input, Orca's when it's back on the host. I have a local prototype working, and I'd like to ask whether you'd consider supporting this upstream.
> >
> > 1. NVDA can't detect the emulated display.
> >
> > NVDA's Baum driver treats 0403:FE72 as a serial device. 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). chardev/baum.c reads the 0x15 request but never replies, so NVDA reports "No Baum display found", even with an FTDI COM-port driver that covers FE72. Replying to "protocol on" with the identity and the cell count fixes it. As far as I can tell, that's what real displays do.
> >
> > 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. 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. BRLTTY then switches between the two clients on the same tty without reconnecting, and each side's last content comes back straight away. Under libvirt, QEMU has no controlling tty, so I also set CONTROLVT in the environment.
> >
> > Questions:
> >
> > - 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?
> >
> > One caveat: I built my local prototype with an AI assistant (Claude). Because of QEMU's code-provenance policy, I can't submit it, and I'm deliberately not sending you the code, so nothing you write is derived from it. I'm not able to write these patches myself without that kind of help.
> >
> > Would you be willing to write them? The first one, answering "protocol on", is a plain bug fix and should be small. The second is a feature request, so please do it whatever way you think is right; my version above is only to show what I'm after. I'm happy to test anything you send, and to provide NVDA and BRLTTY logs with my setup (Brailliant BI 40X, BRLTTY hw driver, Orca on GNOME Wayland, Windows guest with NVDA, libvirt, input-linux with grab_all).
> >
> > --
> > Sincerely, Alexander
> >
>
> --
> Samuel
> «Tiens, quand j'aurai un peu de temps et une partition libre, je crois
>  que je vais essayer de remplacer mes scripts de démarrage par des
>  programmes Windows lancés via Wine et binfmt_misc :-)»
> -+- AGV in Guide du linuxien pervers - "J'sais pas quoi faire... (air connu)"

--
Sincerely, Alexander

Re: 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

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

[Alexander Epaneshnikov]

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

Re: baum: NVDA does not detect usb-braille

[Samuel Thibault]

(splitting the actually-unrelated questions)

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

Does the device sends the cell count first or the device identity first?

Samuel

Re: baum: NVDA does not detect usb-braille

[Alexander Epaneshnikov]

Hello Samuel,

On Sun, Oct 18, 2026 at 09:10:39PM +0200, Samuel Thibault wrote:
> Does the device sends the cell count first or the device identity
> first?

I don't know for sure, as I don't have a real Baum display; mine is a
HumanWare Brailliant, which uses its own protocol. The comment in
NVDA's driver lists them as "device id, serial number and number of
cells", so the identity seems to come first, but that is the only hint
I have. BRLTTY's Baum driver doesn't use 0x15 at all, it asks for each
of them explicitly.

NVDA itself doesn't depend on the order: it stores the cell count and
the identity separately as they arrive and continues once it has both.
I tested sending the identity first and then the cell count, and NVDA
detected the display.

On Sun, Oct 18, 2026 at 09:10:39PM +0200, Samuel Thibault wrote:
> (splitting the actually-unrelated questions)
>
> 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:
> > > 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.
>
> Does the device sends the cell count first or the device identity first?
>
> Samuel

--
Sincerely, Alexander

Re: baum: NVDA does not detect usb-braille

[Samuel Thibault]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

Re,

Alexander Epaneshnikov, le dim. 18 oct. 2026 22:35:58 +0300, a ecrit:
> On Sun, Oct 18, 2026 at 09:10:39PM +0200, Samuel Thibault wrote:
> > Does the device sends the cell count first or the device identity
> > first?
> 
> I don't know for sure, as I don't have a real Baum display; mine is a
> HumanWare Brailliant, which uses its own protocol. The comment in
> NVDA's driver lists them as "device id, serial number and number of
> cells", so the identity seems to come first, but that is the only hint
> I have. BRLTTY's Baum driver doesn't use 0x15 at all, it asks for each
> of them explicitly.
> 
> NVDA itself doesn't depend on the order: it stores the cell count and
> the identity separately as they arrive and continues once it has both.
> I tested sending the identity first and then the cell count, and NVDA
> detected the display.

Ok, could you check the attached patch?

Thanks,
Samuel

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2360 bytes --]

diff --git a/chardev/baum.c b/chardev/baum.c
index 166d6f2f09..db0a4fff75 100644
--- a/chardev/baum.c
+++ b/chardev/baum.c
@@ -97,6 +97,7 @@ struct BaumChardev {
     brlapi_fileDescriptor brlapi_fd;
     unsigned int x, y;
     bool deferred_init;
+    bool protocol_on;
 
     uint8_t in_buf[BUF_SIZE];
     uint8_t in_buf_used;
@@ -337,13 +338,27 @@ static void baum_write_packet(BaumChardev *baum, const uint8_t *buf, int len)
     }
 }
 
+static void baum_send_cell_count(BaumChardev *baum)
+{
+    uint8_t cell_count[] = { BAUM_RSP_CellCount, baum->x * baum->y };
+    baum_write_packet(baum, cell_count, sizeof(cell_count));
+}
+
+static void baum_send_device_identity(BaumChardev *baum)
+{
+    uint8_t identity[17] = { BAUM_RSP_DeviceIdentity,
+        'B','a','u','m',' ','V','a','r','i','o' };
+    identity[11] = '0' + baum->x / 10;
+    identity[12] = '0' + baum->x % 10;
+    baum_write_packet(baum, identity, sizeof(identity));
+}
+
 /* Called when the other end seems to have a wrong idea of our display size */
 static void baum_cellCount_timer_cb(void *opaque)
 {
     BaumChardev *baum = BAUM_CHARDEV(opaque);
-    uint8_t cell_count[] = { BAUM_RSP_CellCount, baum->x * baum->y };
     DPRINTF("Timeout waiting for DisplayData, sending cell count\n");
-    baum_write_packet(baum, cell_count, sizeof(cell_count));
+    baum_send_cell_count(baum);
 }
 
 /* Try to interpret a whole incoming packet */
@@ -441,17 +456,18 @@ static int baum_eat_packet(BaumChardev *baum, const uint8_t *buf, int len)
         uint8_t protocol;
         DPRINTF("SetProtocol\n");
         EAT(protocol);
-        /* ignore */
+        if (!baum->protocol_on && protocol) {
+            /* Switching on, answer with device identity and cell count */
+            baum_send_device_identity(baum);
+            baum_send_cell_count(baum);
+        }
+        baum->protocol_on = protocol;
         break;
     }
     case BAUM_REQ_GetDeviceIdentity:
     {
-        uint8_t identity[17] = { BAUM_RSP_DeviceIdentity,
-            'B','a','u','m',' ','V','a','r','i','o' };
         DPRINTF("GetDeviceIdentity\n");
-        identity[11] = '0' + baum->x / 10;
-        identity[12] = '0' + baum->x % 10;
-        baum_write_packet(baum, identity, sizeof(identity));
+        baum_send_device_identity(baum);
         break;
     }
     case BAUM_REQ_GetVersionNumber:

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

[Samuel Thibault]

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.

> 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 :/

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

Samuel

Re: 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

Re: 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

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

[Alexander Epaneshnikov]

On Sun, Oct 18, 2026 at 09:30:51PM +0200, Samuel Thibault wrote:
> 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.

Understood, thanks. The exclusive grab itself is already part of
input-linux upstream, so the change would only let baum follow a grab
that QEMU already does. But I agree it is up to the QEMU UI/input
maintainers whether they want that; if anyone on qemu-devel has an
opinion, I'd be glad to hear it. Until then I'll keep it as a local
patch.

> Samuel

--
Sincerely, Alexander