qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH v2] ui/gtk: Allow user to select monitor number to display qe


From: 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
Date: Mon, 21 Jun 2021 07:23:47 +0000

Hi Gerd,

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).
sweeaun: Sure, I will make sure that is mentioned clearly in documentation.  

Well, wouldn't it make sense to have monitor=<nr> work for both full-screen=on 
and full-screen=off cases?
sweeaun:  Yes. That will be better option for user. However, I not managed to 
find other GTK window API that can set window into monitor rather than 
gtk_window_fullscreen_on_monitor so far.    

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.
sweeaun: Alright. 

Regards,
SweeAun

-----Original Message-----
From: Gerd Hoffmann <kraxel@redhat.com> 
Sent: Monday, June 21, 2021 2:52 PM
To: Khor, Swee Aun <swee.aun.khor@intel.com>
Cc: Markus Armbruster <armbru@redhat.com>; Romli, Khairul Anuar 
<khairul.anuar.romli@intel.com>; eblake@redhat.com; qemu-devel@nongnu.org; 
Kasireddy, Vivek <vivek.kasireddy@intel.com>
Subject: Re: [PATCH v2] ui/gtk: Allow user to select monitor number to display 
qemu in full screen through new gtk display option

  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=<nr> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]