| Message ID | 20220917000731.465003-1-vivek.kasireddy@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ui/gtk: Add a new parameter to assign connectors/monitors to Guests' windows | expand |
Any overlap with Dongwon Kim's "[PATCH v5 0/2] handling guest multiple displays"? Message-Id: <20220718233009.18780-1-dongwon.kim@intel.com> https://lists.nongnu.org/archive/html/qemu-devel/2022-07/msg03212.html
Hi Markus, > Any overlap with Dongwon Kim's "[PATCH v5 0/2] handling guest multiple > displays"? [Kasireddy, Vivek] Yes, there is some overlap but as I mentioned in the cover letter, this series is intended to replace Dongwon's series dealing with multiple displays. > > Message-Id: <20220718233009.18780-1-dongwon.kim@intel.com> > https://lists.nongnu.org/archive/html/qemu-devel/2022-07/msg03212.html [Kasireddy, Vivek] We felt that using monitor numbers for display/VC assignment would be cumbersome for users. And, given that his series does not take into account monitor unplug/hotplug events, it's effectiveness would be limited compared to this one. Thanks, Vivek
"Kasireddy, Vivek" <vivek.kasireddy@intel.com> writes: > Hi Markus, > >> Any overlap with Dongwon Kim's "[PATCH v5 0/2] handling guest multiple >> displays"? > > [Kasireddy, Vivek] Yes, there is some overlap but as I mentioned in the cover letter, > this series is intended to replace Dongwon's series dealing with multiple displays. I have no idea how I missed that part of your cover letter %-} Dongwon Kim, would this series work for you? >> Message-Id: <20220718233009.18780-1-dongwon.kim@intel.com> >> https://lists.nongnu.org/archive/html/qemu-devel/2022-07/msg03212.html > > [Kasireddy, Vivek] We felt that using monitor numbers for display/VC assignment > would be cumbersome for users. And, given that his series does not take into account > monitor unplug/hotplug events, it's effectiveness would be limited compared to > this one. Thanks!
Hi Markus, Vivek and I have discussed this already. I am fine with replacing my old series with this. Thanks, DW On 9/20/2022 11:06 PM, Markus Armbruster wrote: > "Kasireddy, Vivek" <vivek.kasireddy@intel.com> writes: > >> Hi Markus, >> >>> Any overlap with Dongwon Kim's "[PATCH v5 0/2] handling guest multiple >>> displays"? >> [Kasireddy, Vivek] Yes, there is some overlap but as I mentioned in the cover letter, >> this series is intended to replace Dongwon's series dealing with multiple displays. > I have no idea how I missed that part of your cover letter %-} > > Dongwon Kim, would this series work for you? > >>> Message-Id: <20220718233009.18780-1-dongwon.kim@intel.com> >>> https://lists.nongnu.org/archive/html/qemu-devel/2022-07/msg03212.html >> [Kasireddy, Vivek] We felt that using monitor numbers for display/VC assignment >> would be cumbersome for users. And, given that his series does not take into account >> monitor unplug/hotplug events, it's effectiveness would be limited compared to >> this one. > Thanks! >
"Kim, Dongwon" <dongwon.kim@intel.com> writes: > Hi Markus, > > Vivek and I have discussed this already. I am fine with replacing my old series with this. Good to know, thank you!
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 <dongwon.kim@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Thomas Huth <thuth@redhat.com> 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(-)