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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED88FC48BE5 for ; Mon, 21 Jun 2021 06:52:46 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 8E8FA6109E for ; Mon, 21 Jun 2021 06:52:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E8FA6109E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lvDnZ-00042V-D1 for qemu-devel@archiver.kernel.org; Mon, 21 Jun 2021 02:52:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvDmr-0003M0-Rk for qemu-devel@nongnu.org; Mon, 21 Jun 2021 02:52:01 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:45291) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvDmp-0007Xd-Gm for qemu-devel@nongnu.org; Mon, 21 Jun 2021 02:52:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624258316; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ldG/gtqmbOBVxB9WER+y1/b1HmdfeI9EgiX2I5FJSf4=; b=fkzmMv9EPmR+9EZI3x58zi9qGp7UfxfJQtrobUpA//c1Qv6WLARJuLyhHuwaT24gikjLD5 9OxC+OZYUAAWiIxNIATXU3OU/+9Si2VpkzoS0GxWbMrgUfq7zZmzxZw2uxGjAXk6Jprqk8 mG+KC4I+TUnrQ03T7NHRoN3MGC9IuhQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-257-MCG73xiaPKyNjipypa_MZw-1; Mon, 21 Jun 2021 02:51:52 -0400 X-MC-Unique: MCG73xiaPKyNjipypa_MZw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 99DFD100B3B2; Mon, 21 Jun 2021 06:51:50 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-112-38.ams2.redhat.com [10.36.112.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 408CA1A875; Mon, 21 Jun 2021 06:51:50 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 981C718000B4; Mon, 21 Jun 2021 08:51:48 +0200 (CEST) Date: Mon, 21 Jun 2021 08:51:48 +0200 From: Gerd Hoffmann To: "Khor, Swee Aun" Subject: Re: [PATCH v2] ui/gtk: Allow user to select monitor number to display qemu in full screen through new gtk display option Message-ID: <20210621065148.o7yggutrxgvdnpc7@sirius.home.kraxel.org> References: <20210617020609.18089-1-swee.aun.khor@intel.com> <8735tfsa79.fsf@dusky.pond.sub.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=216.205.24.124; envelope-from=kraxel@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.299, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Romli, Khairul Anuar" , "Kasireddy, Vivek" , "eblake@redhat.com" , Markus Armbruster , "qemu-devel@nongnu.org" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hi, > " Your new option argument seems to count monitors from 1, while GTK counts them from zero. Why the difference?" > sweeaun: It is due to gtk_window_fullscreen_on_monitor monitor index is started from zero. I am not using zero as starting index of new option argument to make easier for user. Example, if there is 2 monitors, then argument option can be monitor 1 or 2. Last number will matched with total monitors which can avoid confusion for user. That is my thought. Start counting from zero makes sense too. Matter of tasts. We have examples for both in the qemu source tree. So, whatever you pick, this clearly needs documentation (in ui.json option description). > "Your documentation states that @monitor applies only "in full screen", but this code is not guarded by if (opts->full_screen). Why is that okay?" > sweeaun: It doesn’t need to be guarded by if (opts->full_screen), as gtk_window_fullscreen_on_monitor will enable the full screen by itself. Well, wouldn't it make sense to have monitor= work for both full-screen=on and full-screen=off cases? > sweeaun: Based on my observation, when specific monitor device disconnected after QEMU launched on it, QEMU application will not be visible but QEMU application still running and screen framebuffer size is not being changed at all. QEMU application will be visible once you connect back the monitor. Well, that probably depends on the display server and might even be configurable. I've seen different ways to handle that, most common ones being (a) do nothing or (b) trying move all windows to the monitor which is still connected. I don't think qemu has to worry much here, and trying to automatically adapt to hot-plugged monitors might even have bad interactions with whatever the display server is going to do. take care, Gerd