From: Justinien Bouron <justinien.bouron@gmail.com>
To: berrange@redhat.com
Cc: armbru@redhat.com, eblake@redhat.com, eduardo@habkost.net,
justinien.bouron@gmail.com, kraxel@redhat.com,
marcandre.lureau@redhat.com, pbonzini@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [PATCH] input-linux: Add option to not grab a device upon guest startup
Date: Fri, 8 Mar 2024 06:34:59 -0800 [thread overview]
Message-ID: <20240308143459.2970899-1-justinien.bouron@gmail.com> (raw)
In-Reply-To: <ZerPYH7KkLpmgTEV@redhat.com>
> > > This last two lines doesn't make sense to me. Isn't the grab
> > > toggling entirely in control of the QEMU process, regardless
> > > of what state the guest is at ?
> >
> > Actually, you're right, they do not make sense. This issue of having the guest
> > taking a while to start and the toggle keys not working, only seem to appear
> > when running the VM under libvirt. I was not able to reproduce this issue when
> > running qemu directly from the command line. So either this is a libvirt issue
> > or something related to my setup (VFIO with GPU passthrough, so a lot can go
> > wrong).
> >
> > Should I send a new version of the patch with an updated commit message that
> > does not mention this issue?
>
> If that probem does not exist, what is the compelling reason to
> add this patch ?
I still think this patch is useful. Having the guest "steal" the kb/mouse from
the host immediately upon starting is frankly annoying and most of the time
unnecessary as at this point the guest is barely booting anyway. Most of the
time I don't need/want to redirect the kb/mouse until the guest is fully booted
and instead want to do something on the host while the guest is starting in the
background. So I end up having to press the toggle keys every time after
starting the guest just so I can keep control of my inputs. This might seem like
a minor annoyance but it is still that, an annoyance.
This can get particularly annoying if the guest is started from a script. In
this situation the guest may not necessarily be started immediately upon running
the script depending on what the script is doing prior to the `virsh start`
command. So you can't tell exactly when your kb/mouse are going to be grabbed
from you. If you do something else on your host in the meantime, while the
script is running in the background, you end up having your inputs grabbed from
you without notice.
There are a few posts[1][2] on the internet asking how to prevent evdev grabbing
upon boot, so it seems that I am not the only one that would like to see such an
option.
[1] https://www.reddit.com/r/VFIO/comments/14xuksq/evedv_passthough_dont_grab_on_start/
[2] https://www.reddit.com/r/VFIO/comments/frbk0q/disabling_auto_keyboard_grab_evdev/
next prev parent reply other threads:[~2024-03-08 14:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 6:28 [PATCH] input-linux: Add option to not grab a device upon guest startup Justinien Bouron
2024-03-07 9:54 ` Daniel P. Berrangé
2024-03-08 3:38 ` Justinien Bouron
2024-03-08 8:42 ` Daniel P. Berrangé
2024-03-08 14:34 ` Justinien Bouron [this message]
2024-03-15 2:36 ` Justinien Bouron
2024-03-15 6:06 ` Marc-André Lureau
2024-03-15 6:07 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240308143459.2970899-1-justinien.bouron@gmail.com \
--to=justinien.bouron@gmail.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).