Justinien Bouron writes:
> Depending on your use-case, it might be inconvenient to have qemu grab
> the input device immediately upon starting the guest, especially if the
> guest takes a while to start in which case it may take a few seconds
> before being able to release the device via the
Hi Justinien
On Fri, Mar 15, 2024 at 6:37 AM Justinien Bouron
wrote:
>
> Just a ping to make sure this patch hasn't been lost in the noise.
> Any chance to get this merged? Should I send a v2 with a revised commit
> message?
>
It's too late for 9.0. Please send a v2 with updated commit
Just a ping to make sure this patch hasn't been lost in the noise.
Any chance to get this merged? Should I send a v2 with a revised commit message?
Regards,
Justinien
> > > 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
On Thu, Mar 07, 2024 at 07:38:27PM -0800, Justinien Bouron wrote:
> > 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
> 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,
On Wed, Mar 06, 2024 at 10:28:22PM -0800, Justinien Bouron wrote:
> Depending on your use-case, it might be inconvenient to have qemu grab
> the input device immediately upon starting the guest, especially if the
> guest takes a while to start in which case it may take a few seconds
> before being
