From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Dongwon Kim <dongwon.kim@intel.com>
Cc: qemu-devel@nongnu.org, philmd@redhat.com, kraxel@redhat.com,
pbonzini@redhat.com, Vivek Kasireddy <vivek.kasireddy@intel.com>
Subject: Re: [PATCH 2/3] ui/gtk: detach_all option for making all VCs detached upon starting
Date: Wed, 4 May 2022 09:28:01 +0100 [thread overview]
Message-ID: <YnI5EeToL+y6i0ER@redhat.com> (raw)
In-Reply-To: <20220503232144.GB352@dongwonk-MOBL.amr.corp.intel.com>
On Tue, May 03, 2022 at 04:21:44PM -0700, Dongwon Kim wrote:
> On Tue, May 03, 2022 at 10:12:43AM +0100, Daniel P. Berrangé wrote:
> > On Thu, Apr 28, 2022 at 04:13:03PM -0700, Dongwon Kim wrote:
> > > With "detach-all=on" for display, QEMU starts with all VC windows
> > > detached automatically.
> > >
> > > If used with "full-screen=on", it places individual windows (from
> > > top window) starting from monitor 0 or monitor n in case monitor=n.
> > >
> > > In case # mon < # VCs, only same number of VCs as # mon will be sent to
> > > the monitors for full-screen while others are remaining in windowed-mode.
> > >
> > > Target monitor number for individual VC is rotated in case monitor=n
> > > (n != 0) (e.g. if monitor=1 and # VCs = 2, the top window will be
> > > full-screened on monitor 1 and top second window will be full-screened
> > > on monitor 0.)
> >
> > I tend to wonder whether we actually need this at all, as opposed
> > to just changing QEMU's behaviour by default.
> >
> > It makes sense to have tabs per-VC for the things like the HMP
> > console, serial ports, etc, but I think graphical video outputs
> > should always be displayed as multiple windows. Putting graphical
> > outputs as tabs rather defeats the purpose of having multiple
> > outputs IMHO.
> >
> > IOW, why won't we just create 1 gtk window per graphical output
> > all the time.
>
> I got your point but I think this requires changes in the
> policy, which I guess need community-wide agreement. Why don't we move
> on with this new option and at the same time start the discussion?
Once we add a CLI option is it is more complicated to remove it again
later. So if we don't actually need it, it is better not to add it in
the first place.
> One more point is, I tried to find out but I couldn't think of any good way
> to distinguish between guest output consoles and other consoles. Do you
> have any thought on this?
There's a helper:
bool qemu_console_is_graphic(QemuConsole *con);
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 :|
next prev parent reply other threads:[~2022-05-04 8:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-28 23:13 [PATCH 0/3] ui/gtk: new options, monitor and detach-all Dongwon Kim
2022-04-28 23:13 ` [PATCH 1/3] ui/gtk: new param monitor to specify target monitor for launching QEMU Dongwon Kim
2022-05-03 9:15 ` Daniel P. Berrangé
2022-05-03 23:14 ` Dongwon Kim
2022-05-09 21:31 ` Dongwon Kim
2022-05-10 10:58 ` Gerd Hoffmann
2022-05-17 7:46 ` Markus Armbruster
2022-04-28 23:13 ` [PATCH 2/3] ui/gtk: detach_all option for making all VCs detached upon starting Dongwon Kim
2022-05-03 9:12 ` Daniel P. Berrangé
2022-05-03 23:21 ` Dongwon Kim
2022-05-04 8:28 ` Daniel P. Berrangé [this message]
2022-04-28 23:13 ` [PATCH 3/3] ui/gtk: specify detached window's size and location Dongwon Kim
2022-05-03 9:17 ` Daniel P. Berrangé
2022-05-03 23:33 ` Dongwon Kim
2022-05-06 16:34 ` Daniel P. Berrangé
2022-05-06 17:05 ` Dongwon Kim
2022-05-31 20:33 ` [PATCH 0/3] ui/gtk: new options, monitor and detach-all Dongwon Kim
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=YnI5EeToL+y6i0ER@redhat.com \
--to=berrange@redhat.com \
--cc=dongwon.kim@intel.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vivek.kasireddy@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.