From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CA9FEC54E49 for ; Thu, 7 Mar 2024 09:55:13 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1riASr-0003nL-TI; Thu, 07 Mar 2024 04:55:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1riASq-0003me-6M for qemu-devel@nongnu.org; Thu, 07 Mar 2024 04:55:00 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1riASo-0006xw-HO for qemu-devel@nongnu.org; Thu, 07 Mar 2024 04:54:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709805297; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=KMCkLJv3XeTbyWITavrwpOnyQ4QbA4RPBWXaHDSuUiU=; b=WrnWUmycwaWDbkh1qTqr/97D6fR28KrkYWfAcBGdaLzrlWkEWPc4WpF9tvw3j20OqN1RnK tSvZR+Eab640MJ8C8x6o7CUviwyT61Yb+7EtySczeHZMymgeWKYDsJIzNdKECy1/ErqGz4 rfJT9zJ/73PnE7k+4r3DF69XjpOGroQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-169-YnT2uxxyP162wKqFmgqVYg-1; Thu, 07 Mar 2024 04:54:53 -0500 X-MC-Unique: YnT2uxxyP162wKqFmgqVYg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 62698185A783; Thu, 7 Mar 2024 09:54:53 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8C5D6492BCB; Thu, 7 Mar 2024 09:54:51 +0000 (UTC) Date: Thu, 7 Mar 2024 09:54:49 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Justinien Bouron Cc: Paolo Bonzini , Eduardo Habkost , Eric Blake , Markus Armbruster , Gerd Hoffmann , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , qemu-devel@nongnu.org Subject: Re: [PATCH] input-linux: Add option to not grab a device upon guest startup Message-ID: References: <20240307062823.2377318-1-justinien.bouron@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240307062823.2377318-1-justinien.bouron@gmail.com> User-Agent: Mutt/2.2.12 (2023-09-09) X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 Received-SPF: pass client-ip=170.10.129.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.365, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org 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 able to release the device via the toggle combination. 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 ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|