From patchwork Sat Sep 17 00:07:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Kasireddy, Vivek" X-Patchwork-Id: 12978920 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 35347ECAAA1 for ; Sat, 17 Sep 2022 00:30:39 +0000 (UTC) Received: from localhost ([::1]:49706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oZLjC-0000tV-DK for qemu-devel@archiver.kernel.org; Fri, 16 Sep 2022 20:30:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZLgF-0005mg-BV for qemu-devel@nongnu.org; Fri, 16 Sep 2022 20:27:35 -0400 Received: from mga17.intel.com ([192.55.52.151]:23538) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZLgC-0000kB-Fw for qemu-devel@nongnu.org; Fri, 16 Sep 2022 20:27:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663374452; x=1694910452; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=YjTlBqKyeKQ6a1J8XTBVrW5A7/E2t8WV2eCMe+aFiiI=; b=ENsG7o3EGbFEPqtBOPGxO1fmRxG9ZmJMSLqmEjOOHvFvw2VHvFtkYSSB uvvGr6sCXk99SzjANgoJnZU6L18mtiga1GegNzapRptFJ8KS7P0kjHOeg FQK8odlKZ84O50H8BPrSTk663yPdu8LThnp1hNdMQaVJlJA4EgLGtMsQD v9Y+ZiwGuewB9JVJNXZDxUZ06G+vwGWexYN4nhc/YSjCceuW8wyPjrnT0 AGVNadAjUmXJuuDsREeJ9zROYSNvzXsR9Z4eUk8aI1/BEpYvzSuTYS786 wskQYD1O7C+k67Qo5bpUQR0W+g4a0326eOzA9PBoqVMT51/HuTqtzJhmi g==; X-IronPort-AV: E=McAfee;i="6500,9779,10472"; a="279489393" X-IronPort-AV: E=Sophos;i="5.93,321,1654585200"; d="scan'208";a="279489393" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2022 17:27:20 -0700 X-IronPort-AV: E=Sophos;i="5.93,321,1654585200"; d="scan'208";a="760235119" Received: from vkasired-desk2.fm.intel.com ([10.105.128.127]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2022 17:27:20 -0700 From: Vivek Kasireddy To: qemu-devel@nongnu.org Cc: Vivek Kasireddy , Dongwon Kim , Gerd Hoffmann , =?utf-8?q?Daniel_P_=2E_Berrang=C3=A9?= , Markus Armbruster , =?utf-8?q?Philippe_Mathieu-Daud?= =?utf-8?q?=C3=A9?= , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , Thomas Huth Subject: [PATCH v1 0/3] ui/gtk: Add a new parameter to assign connectors/monitors to Guests' windows Date: Fri, 16 Sep 2022 17:07:28 -0700 Message-Id: <20220917000731.465003-1-vivek.kasireddy@intel.com> X-Mailer: git-send-email 2.37.2 MIME-Version: 1.0 Received-SPF: pass client-ip=192.55.52.151; envelope-from=vivek.kasireddy@intel.com; helo=mga17.intel.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" There is a need (expressed by several customers/users) to assign ownership of one or more physical monitors/connectors to individual Guests such that there is a clear notion of which Guest's contents are being displayed on any given monitor. Given that there is always a Display Server/Compositor running on the Host, monitor ownership can never truly be transferred to Guests. However, the closest we can come to realizing this concept is to request the Host compositor to fullscreen the Guest's windows on individual monitors. This way, it would become possible to have 4 different Guests' windows be displayed on 4 different monitors or a single Guest's windows (or virtual consoles/outputs) be displayed on 4 monitors or any such combination. This patch series attempts to accomplish this by introducing a new parameter named "connector" to assign the monitors to the GFX VCs associated with a Guest. If the assigned monitor is not connected, then the Guest's window would not be displayed anywhere similar to how a Host compositor would behave when the connectors are not connected. Once the monitor is hotplugged, the Guest's window(s) would be fullscreened on the assigned monitor. The first patch is just a bug fix to destroy context related objects when an associated window is destroyed. The second patch is a minor refactor and the third and last patch introduces the new parameter. This patch series is expected to supersede a similar series from Dongwon Kim here: https://lists.nongnu.org/archive/html/qemu-devel/2022-07/msg03214.html Example Usage: -device virtio-gpu-pci,max_outputs=2,blob=true...... -display gtk,gl=on,connector.0=eDP-1,connector.1=DP-1..... Cc: Dongwon Kim Cc: Gerd Hoffmann Cc: Daniel P. Berrangé Cc: Markus Armbruster Cc: Philippe Mathieu-Daudé Cc: Marc-André Lureau Cc: Thomas Huth Vivek Kasireddy (3): ui/gtk: Disable the scanout when a detached tab is closed ui/gtk: Factor out tab window creation into a separate function ui/gtk: Add a new parameter to assign connectors/monitors to GFX VCs qapi/ui.json | 9 +- qemu-options.hx | 1 + ui/gtk-egl.c | 2 + ui/gtk-gl-area.c | 2 + ui/gtk.c | 220 ++++++++++++++++++++++++++++++++++++++++++----- 5 files changed, 211 insertions(+), 23 deletions(-)