qapi/ui.json | 25 +++- include/ui/gtk.h | 1 + ui/gtk.c | 301 +++++++++++++++++++++++++++++++++++++++++++---- qemu-options.hx | 4 + 4 files changed, 308 insertions(+), 23 deletions(-)
From: Dongwon Kim <dongwon.kim@intel.com>
This patch series is a replacement of
https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html
There is a need, expressed by several users, to assign ownership of one
or more physical monitors/connectors to individual guests. This creates
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 approximation is to request the host compositor to
fullscreen the guest's windows on individual monitors. This allows for
various configurations, such as displaying four different guests' windows
on four different monitors, a single guest's windows (or virtual consoles)
on four monitors, or any similar combination.
This patch series attempts to accomplish this by introducing a new
parameter named "connector" to assign monitors to the GFX VCs associated
with a guest. If the assigned monitor is not connected, the guest's window
will not be displayed, similar to how a host compositor behaves when
connectors are not connected. Once the monitor is hot-plugged, the guest's
window(s) will be positioned on the assigned monitor.
Usage example:
-display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2...
In this example, the first graphics virtual console will be placed on the
DP-1 display, the second on eDP-1, and the third on HDMI-2.
v2: Connectors is now in a string format that includes all connector names
separated with a colon (previously it was a linked list)
Code refactoring
Vivek Kasireddy (2):
ui/gtk: Factor out tab window creation into a separate
ui/gtk: Add a new parameter to assign connectors/monitors
qapi/ui.json | 25 +++-
include/ui/gtk.h | 1 +
ui/gtk.c | 301 +++++++++++++++++++++++++++++++++++++++++++----
qemu-options.hx | 4 +
4 files changed, 308 insertions(+), 23 deletions(-)
--
2.34.1
Hi On Fri, May 31, 2024 at 11:00 PM <dongwon.kim@intel.com> wrote: > From: Dongwon Kim <dongwon.kim@intel.com> > > This patch series is a replacement of > https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html > > There is a need, expressed by several users, to assign ownership of one > or more physical monitors/connectors to individual guests. This creates > 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 approximation is to request the host compositor to > fullscreen the guest's windows on individual monitors. This allows for > various configurations, such as displaying four different guests' windows > on four different monitors, a single guest's windows (or virtual consoles) > on four monitors, or any similar combination. > > This patch series attempts to accomplish this by introducing a new > parameter named "connector" to assign monitors to the GFX VCs associated > with a guest. If the assigned monitor is not connected, the guest's window > will not be displayed, similar to how a host compositor behaves when > connectors are not connected. Once the monitor is hot-plugged, the guest's > window(s) will be positioned on the assigned monitor. > > Usage example: > > -display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2... > > In this example, the first graphics virtual console will be placed on the > DP-1 display, the second on eDP-1, and the third on HDMI-2. > > Unfortunately, this approach with GTK is doomed. gtk4 dropped the gtk_window_set_position() altogether. It's not even clear how the different monitors/outputs/connectors are actually named, whether they are stable etc (not mentioning the portability). Window placement & geometry is a job for the compositor. Can you discuss this issue with GTK devs & the compositor you are targeting? -- Marc-André Lureau
Hi Marc-André,
On 6/4/2024 3:37 AM, Marc-André Lureau wrote:
> Hi
>
> On Fri, May 31, 2024 at 11:00 PM <dongwon.kim@intel.com
> <mailto:dongwon.kim@intel.com>> wrote:
>
> From: Dongwon Kim <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>
>
> This patch series is a replacement of
> https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html
> <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html>
>
> There is a need, expressed by several users, to assign ownership of one
> or more physical monitors/connectors to individual guests. This creates
> 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 approximation is to request the host compositor to
> fullscreen the guest's windows on individual monitors. This allows for
> various configurations, such as displaying four different guests'
> windows
> on four different monitors, a single guest's windows (or virtual
> consoles)
> on four monitors, or any similar combination.
>
> This patch series attempts to accomplish this by introducing a new
> parameter named "connector" to assign monitors to the GFX VCs associated
> with a guest. If the assigned monitor is not connected, the guest's
> window
> will not be displayed, similar to how a host compositor behaves when
> connectors are not connected. Once the monitor is hot-plugged, the
> guest's
> window(s) will be positioned on the assigned monitor.
>
> Usage example:
>
> -display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2...
>
> In this example, the first graphics virtual console will be placed
> on the
> DP-1 display, the second on eDP-1, and the third on HDMI-2.
>
>
> Unfortunately, this approach with GTK is doomed. gtk4 dropped the
> gtk_window_set_position() altogether.
Do you mean we have a plan to lift GTK version in QEMU? Are we going to
lose all GTK3 specific features?
>
> It's not even clear how the different monitors/outputs/connectors are
> actually named, whether they are stable etc (not mentioning the
> portability).
>
> Window placement & geometry is a job for the compositor. Can you discuss
> this issue with GTK devs & the compositor you are targeting?
I guess you are talking about wayland compositor. We are mainly using
Xorg on the host and this feature works pretty good on it. I am
wondering if we limit the feature to Xorg case or adding some warning
messages with error return in case any of parts is not working?
(like the warning message I added
+ model = gdk_monitor_get_model(monitor);
+ if (!model) {
+ g_warning("retrieving connector name using\n"
+ "gdk_monitor_get_model isn't supported\n"
+ "please do not use connectors param in\n"
+ "current environment\n");
+ return -1;
+ }
)
>
> --
> Marc-André Lureau
Hi
On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon <dongwon.kim@intel.com> wrote:
> Hi Marc-André,
>
> On 6/4/2024 3:37 AM, Marc-André Lureau wrote:
> > Hi
> >
> > On Fri, May 31, 2024 at 11:00 PM <dongwon.kim@intel.com
> > <mailto:dongwon.kim@intel.com>> wrote:
> >
> > From: Dongwon Kim <dongwon.kim@intel.com <mailto:
> dongwon.kim@intel.com>>
> >
> > This patch series is a replacement of
> > https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html
> > <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html>
> >
> > There is a need, expressed by several users, to assign ownership of
> one
> > or more physical monitors/connectors to individual guests. This
> creates
> > 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 approximation is to request the host compositor
> to
> > fullscreen the guest's windows on individual monitors. This allows
> for
> > various configurations, such as displaying four different guests'
> > windows
> > on four different monitors, a single guest's windows (or virtual
> > consoles)
> > on four monitors, or any similar combination.
> >
> > This patch series attempts to accomplish this by introducing a new
> > parameter named "connector" to assign monitors to the GFX VCs
> associated
> > with a guest. If the assigned monitor is not connected, the guest's
> > window
> > will not be displayed, similar to how a host compositor behaves when
> > connectors are not connected. Once the monitor is hot-plugged, the
> > guest's
> > window(s) will be positioned on the assigned monitor.
> >
> > Usage example:
> >
> > -display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2...
> >
> > In this example, the first graphics virtual console will be placed
> > on the
> > DP-1 display, the second on eDP-1, and the third on HDMI-2.
> >
> >
> > Unfortunately, this approach with GTK is doomed. gtk4 dropped the
> > gtk_window_set_position() altogether.
>
> Do you mean we have a plan to lift GTK version in QEMU? Are we going to
> lose all GTK3 specific features?
>
No concrete plan, no. But eventually GTK3 will go away some day.
fwiw, I wish QEMU wouldn't have N built-in UIs/Spice/VNC, but different
projects elsewhere using -display dbus. There is
https://gitlab.gnome.org/GNOME/libmks or
https://gitlab.com/marcandre.lureau/qemu-display gtk4 efforts.
> >
> > It's not even clear how the different monitors/outputs/connectors are
> > actually named, whether they are stable etc (not mentioning the
> > portability).
> >
> > Window placement & geometry is a job for the compositor. Can you discuss
> > this issue with GTK devs & the compositor you are targeting?
>
> I guess you are talking about wayland compositor. We are mainly using
> Xorg on the host and this feature works pretty good on it. I am
>
Xorg may not be going away soon, but it's used less and less. As one of the
developers, I am no longer running/testing it for a long time. I wish we
would just drop its support tbh.
wondering if we limit the feature to Xorg case or adding some warning
> messages with error return in case any of parts is not working?
> (like the warning message I added
>
> + model = gdk_monitor_get_model(monitor);
> + if (!model) {
> + g_warning("retrieving connector name using\n"
> + "gdk_monitor_get_model isn't supported\n"
> + "please do not use connectors param in\n"
> + "current environment\n");
> + return -1;
> + }
> )
>
Is it really worth maintaining this upstream if we know it will only work
for a diminishing fraction of users?
--
Marc-André Lureau
Hi Marc-André,
On 6/5/2024 12:26 AM, Marc-André Lureau wrote:
> Hi
>
> On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon <dongwon.kim@intel.com
> <mailto:dongwon.kim@intel.com>> wrote:
>
> Hi Marc-André,
>
> On 6/4/2024 3:37 AM, Marc-André Lureau wrote:
> > Hi
> >
> > On Fri, May 31, 2024 at 11:00 PM <dongwon.kim@intel.com
> <mailto:dongwon.kim@intel.com>
> > <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>> wrote:
> >
> > From: Dongwon Kim <dongwon.kim@intel.com
> <mailto:dongwon.kim@intel.com> <mailto:dongwon.kim@intel.com
> <mailto:dongwon.kim@intel.com>>>
> >
> > This patch series is a replacement of
> >
> https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html
> <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html>
> >
> <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html <https://mail.gnu.org/archive/html/qemu-devel/2023-06/msg03989.html>>
> >
> > There is a need, expressed by several users, to assign
> ownership of one
> > or more physical monitors/connectors to individual guests.
> This creates
> > 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 approximation is to request the host
> compositor to
> > fullscreen the guest's windows on individual monitors. This
> allows for
> > various configurations, such as displaying four different guests'
> > windows
> > on four different monitors, a single guest's windows (or virtual
> > consoles)
> > on four monitors, or any similar combination.
> >
> > This patch series attempts to accomplish this by introducing
> a new
> > parameter named "connector" to assign monitors to the GFX VCs
> associated
> > with a guest. If the assigned monitor is not connected, the
> guest's
> > window
> > will not be displayed, similar to how a host compositor
> behaves when
> > connectors are not connected. Once the monitor is
> hot-plugged, the
> > guest's
> > window(s) will be positioned on the assigned monitor.
> >
> > Usage example:
> >
> > -display gtk,gl=on,connectors=DP-1:eDP-1:HDMI-2...
> >
> > In this example, the first graphics virtual console will be
> placed
> > on the
> > DP-1 display, the second on eDP-1, and the third on HDMI-2.
> >
> >
> > Unfortunately, this approach with GTK is doomed. gtk4 dropped the
> > gtk_window_set_position() altogether.
>
> Do you mean we have a plan to lift GTK version in QEMU? Are we going to
> lose all GTK3 specific features?
>
>
> No concrete plan, no. But eventually GTK3 will go away some day.
There are users who still rely on features provided by GTK3 and we also
have customers who are moving from VMware, virtualbox that have
requested for this feature. Their use-cases are current and active. If
windows repositioning won't be supported someday, then we would need to
make this feature obsolete but many users/customers would benefit from
it until then.
>
> fwiw, I wish QEMU wouldn't have N built-in UIs/Spice/VNC, but different
> projects elsewhere using -display dbus. There is
> https://gitlab.gnome.org/GNOME/libmks
> <https://gitlab.gnome.org/GNOME/libmks> or
> https://gitlab.com/marcandre.lureau/qemu-display
> <https://gitlab.com/marcandre.lureau/qemu-display> gtk4 efforts.
As you know, there cannot be a one size fits all solution that would
work for all the users, which is probably why there are many Qemu UIs.
>
>
> >
> > It's not even clear how the different monitors/outputs/connectors
> are
> > actually named, whether they are stable etc (not mentioning the
> > portability).
> >
> > Window placement & geometry is a job for the compositor. Can you
> discuss
> > this issue with GTK devs & the compositor you are targeting?
>
> I guess you are talking about wayland compositor. We are mainly using
> Xorg on the host and this feature works pretty good on it. I am
>
>
> Xorg may not be going away soon, but it's used less and less. As one of
> the developers, I am no longer running/testing it for a long time. I
> wish we would just drop its support tbh.
There are features offered by Xorg that are not offered by Wayland
compositors and again, we have customers that rely on these features.
One of them is the ability to position the window via
gtk_window_set_position(). There are strong arguments
made on either side when it comes to window positioning:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
Until there is a way to do this with Wayland compositors, we have to
unfortunately rely on Gnome + Xorg.
>
> wondering if we limit the feature to Xorg case or adding some warning
> messages with error return in case any of parts is not working?
> (like the warning message I added
>
> + model = gdk_monitor_get_model(monitor);
> + if (!model) {
> + g_warning("retrieving connector name using\n"
> + "gdk_monitor_get_model isn't supported\n"
> + "please do not use connectors param in\n"
> + "current environment\n");
> + return -1;
> + }
> )
>
>
> Is it really worth maintaining this upstream if we know it will only
> work for a diminishing fraction of users?
As mentioned above, we are going to have maintain it for the
customers/users who have use-cases that rely on this.
>
>
>
> --
> Marc-André Lureau
Hi On Tue, Jun 11, 2024 at 10:28 PM Kim, Dongwon <dongwon.kim@intel.com> wrote: > Hi Marc-André, > > On 6/5/2024 12:26 AM, Marc-André Lureau wrote: > > Hi > > > > On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon <dongwon.kim@intel.com > > <mailto:dongwon.kim@intel.com>> wrote: > > Xorg may not be going away soon, but it's used less and less. As one of > > the developers, I am no longer running/testing it for a long time. I > > wish we would just drop its support tbh. > > There are features offered by Xorg that are not offered by Wayland > compositors and again, we have customers that rely on these features. > One of them is the ability to position the window via > gtk_window_set_position(). There are strong arguments > made on either side when it comes to window positioning: > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 > > Until there is a way to do this with Wayland compositors, we have to > unfortunately rely on Gnome + Xorg. > > It's a smaller and smaller number of users. The potential/future users are greater if we focus on Wayland. Fwiw, GNOME (and RHEL) is set to drop Xorg support ( https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98) Btw, there is a similar monitor-mapping functionality implemented in virt-viewer/remote-viewer: https://www.mankier.com/1/virt-viewer#Configuration. Is this something that those users could use instead? -- Marc-André Lureau
On 6/11/2024 11:42 PM, Marc-André Lureau wrote: > Hi > > On Tue, Jun 11, 2024 at 10:28 PM Kim, Dongwon <dongwon.kim@intel.com > <mailto:dongwon.kim@intel.com>> wrote: > > Hi Marc-André, > > On 6/5/2024 12:26 AM, Marc-André Lureau wrote: > > Hi > > > > On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon > <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com> > > <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>> wrote: > > > Xorg may not be going away soon, but it's used less and less. As > one of > > the developers, I am no longer running/testing it for a long time. I > > wish we would just drop its support tbh. > > There are features offered by Xorg that are not offered by Wayland > compositors and again, we have customers that rely on these features. > One of them is the ability to position the window via > gtk_window_set_position(). There are strong arguments > made on either side when it comes to window positioning: > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 <https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247> > > Until there is a way to do this with Wayland compositors, we have to > unfortunately rely on Gnome + Xorg. > > > It's a smaller and smaller number of users. The potential/future users > are greater if we focus on Wayland. Right, but until Gtk + Wayland offers the same feature parity and customization as that of Gtk + Xorg, there will be distros/users that will keep it alive. > > Fwiw, GNOME (and RHEL) is set to drop Xorg support > (https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98 > <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98>) Doesn't look like it is going to happen anytime soon given the massive pushback. > > Btw, there is a similar monitor-mapping functionality implemented in > virt-viewer/remote-viewer: > https://www.mankier.com/1/virt-viewer#Configuration > <https://www.mankier.com/1/virt-viewer#Configuration>. Is this something > that those users could use instead? It looks a bit similar and interesting but one difference is that our feature uses monitor labels such as DP-1, HDMI-2 which is a bit more intuitive. And, the other key difference is that our feature includes "hotplug" functionality where a Guest display/window is deeply tied to a physical monitor to make it appear to the guest that it is dealing with a real physical monitor. In other words, when the physical monitor is unplugged, the associated guest display/window gets destroyed/hidden and gets recreated/shown when the monitor is hotplugged again. > > > -- > Marc-André Lureau
Hi On Thu, Jun 13, 2024 at 3:34 AM Kim, Dongwon <dongwon.kim@intel.com> wrote: > On 6/11/2024 11:42 PM, Marc-André Lureau wrote: > > Hi > > > > On Tue, Jun 11, 2024 at 10:28 PM Kim, Dongwon <dongwon.kim@intel.com > > <mailto:dongwon.kim@intel.com>> wrote: > > > > Hi Marc-André, > > > > On 6/5/2024 12:26 AM, Marc-André Lureau wrote: > > > Hi > > > > > > On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon > > <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com> > > > <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>> > wrote: > > > > > Xorg may not be going away soon, but it's used less and less. As > > one of > > > the developers, I am no longer running/testing it for a long > time. I > > > wish we would just drop its support tbh. > > > > There are features offered by Xorg that are not offered by Wayland > > compositors and again, we have customers that rely on these features. > > One of them is the ability to position the window via > > gtk_window_set_position(). There are strong arguments > > made on either side when it comes to window positioning: > > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 > < > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 > > > > > > Until there is a way to do this with Wayland compositors, we have to > > unfortunately rely on Gnome + Xorg. > > > > > > It's a smaller and smaller number of users. The potential/future users > > are greater if we focus on Wayland. > > Right, but until Gtk + Wayland offers the same feature parity and > customization as that of Gtk + Xorg, there will be distros/users that > will keep it alive. > > > > Fwiw, GNOME (and RHEL) is set to drop Xorg support > > (https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98 > > <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98>) > > Doesn't look like it is going to happen anytime soon given the massive > pushback. > The plan is there, GNOME has made bold moves in the past. There is not much left in the TODO. But yes, it takes a bit longer than expected. > > > > > Btw, there is a similar monitor-mapping functionality implemented in > > virt-viewer/remote-viewer: > > https://www.mankier.com/1/virt-viewer#Configuration > > <https://www.mankier.com/1/virt-viewer#Configuration>. Is this > something > > that those users could use instead? > > It looks a bit similar and interesting but one difference is that our > feature uses monitor labels such as DP-1, HDMI-2 which is a bit more > intuitive. And, the other key difference is that our feature includes > Intuitive, perhaps. Discoverable and portable? "hotplug" functionality where a Guest display/window is deeply tied to a > physical monitor to make it appear to the guest that it is dealing with > a real physical monitor. > In other words, when the physical monitor is unplugged, the associated > guest display/window gets destroyed/hidden and gets recreated/shown when > the monitor is hotplugged again. > > Interesting case that could be added to virt-viewer if it's necessary. > The subject is sufficiently complex that there is already additional documentation/specification in: https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads Honestly, I don't support the idea of duplicating this effort in QEMU. -- Marc-André Lureau
Hi Marc-André, On 6/12/2024 11:56 PM, Marc-André Lureau wrote: > Hi > > On Thu, Jun 13, 2024 at 3:34 AM Kim, Dongwon <dongwon.kim@intel.com > <mailto:dongwon.kim@intel.com>> wrote: > > On 6/11/2024 11:42 PM, Marc-André Lureau wrote: > > Hi > > > > On Tue, Jun 11, 2024 at 10:28 PM Kim, Dongwon > <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com> > > <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>> wrote: > > > > Hi Marc-André, > > > > On 6/5/2024 12:26 AM, Marc-André Lureau wrote: > > > Hi > > > > > > On Tue, Jun 4, 2024 at 9:59 PM Kim, Dongwon > > <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com> > <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>> > > > <mailto:dongwon.kim@intel.com > <mailto:dongwon.kim@intel.com> <mailto:dongwon.kim@intel.com > <mailto:dongwon.kim@intel.com>>>> wrote: > > > > > Xorg may not be going away soon, but it's used less and > less. As > > one of > > > the developers, I am no longer running/testing it for a > long time. I > > > wish we would just drop its support tbh. > > > > There are features offered by Xorg that are not offered by > Wayland > > compositors and again, we have customers that rely on these > features. > > One of them is the ability to position the window via > > gtk_window_set_position(). There are strong arguments > > made on either side when it comes to window positioning: > > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 <https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247> <https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 <https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247>> > > > > Until there is a way to do this with Wayland compositors, we > have to > > unfortunately rely on Gnome + Xorg. > > > > > > It's a smaller and smaller number of users. The potential/future > users > > are greater if we focus on Wayland. > > Right, but until Gtk + Wayland offers the same feature parity and > customization as that of Gtk + Xorg, there will be distros/users that > will keep it alive. > > > > Fwiw, GNOME (and RHEL) is set to drop Xorg support > > (https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98 > <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98> > > <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98 > <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98>>) > > Doesn't look like it is going to happen anytime soon given the massive > pushback. > > > The plan is there, GNOME has made bold moves in the past. There is not > much left in the TODO. But yes, it takes a bit longer than expected. > > > > > > Btw, there is a similar monitor-mapping functionality implemented in > > virt-viewer/remote-viewer: > > https://www.mankier.com/1/virt-viewer#Configuration > <https://www.mankier.com/1/virt-viewer#Configuration> > > <https://www.mankier.com/1/virt-viewer#Configuration > <https://www.mankier.com/1/virt-viewer#Configuration>>. Is this > something > > that those users could use instead? > > It looks a bit similar and interesting but one difference is that our > feature uses monitor labels such as DP-1, HDMI-2 which is a bit more > intuitive. And, the other key difference is that our feature includes > > > Intuitive, perhaps. Discoverable and portable? > > "hotplug" functionality where a Guest display/window is deeply tied to a > physical monitor to make it appear to the guest that it is dealing with > a real physical monitor. > > In other words, when the physical monitor is unplugged, the associated > guest display/window gets destroyed/hidden and gets recreated/shown > when > the monitor is hotplugged again. > > > Interesting case that could be added to virt-viewer if it's necessary. > > The subject is sufficiently complex that there is already additional > documentation/specification in: > https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads <https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads> > > Honestly, I don't support the idea of duplicating this effort in QEMU. Marc-André, My assumption is virt-viewer might not be able to completely replace GTK-UI path in terms of performance and smoothness of display update as (I think) frame copy between processes is implied, which is same as spice-remote viewer. What about display-bus that you have been working on? Would it be a good alternative w.r.t perf concern that I specified above? > > -- > Marc-André Lureau
Hi On Thu, Jun 13, 2024 at 9:08 PM Kim, Dongwon <dongwon.kim@intel.com> wrote: > > "hotplug" functionality where a Guest display/window is deeply tied > to a > > physical monitor to make it appear to the guest that it is dealing > with > > a real physical monitor. > > > > In other words, when the physical monitor is unplugged, the > associated > > guest display/window gets destroyed/hidden and gets recreated/shown > > when > > the monitor is hotplugged again. > > > > > > Interesting case that could be added to virt-viewer if it's necessary. > > > > The subject is sufficiently complex that there is already additional > > documentation/specification in: > > > https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads > < > https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads > > > > > > Honestly, I don't support the idea of duplicating this effort in QEMU. > > Marc-André, > > My assumption is virt-viewer might not be able to completely replace > GTK-UI path in terms of performance and smoothness of display update as > (I think) frame copy between processes is implied, which is same as > There is no frame copy when using DMABUF scanouts between qemu and client. Iow, the performance difference is negligible / noise level. spice-remote viewer. What about display-bus that you have been working > on? Would it be a good alternative w.r.t perf concern that I specified > above? > There shouldn't be much difference for the local DMABUF display case. > > > > > -- > > Marc-André Lureau > > -- Marc-André Lureau
Hi Marc-André, Ok, it is good to know dmabuf is used for sharing the scanout between processes when using dbus or virt-viewer. BTW, I have some more comments on your previous answers. I just copied ans pasted your previous comments. Sorry about any inconvenience caused by this delayed response. [Marc-André] The plan is there, GNOME has made bold moves in the past. There is not much left in the TODO. But yes, it takes a bit longer than expected. [Dongwon] If Gnome abandons Xorg, then users would find other distros or other desktop environments that support Xorg. My point is why should Qemu GTK UI not support those distros/environments that support Xorg today with new features? If maintainability is your concern, again we can offer supporting this feature as long as there is a distro out there that supports Xorg. [Marc-André] Intuitive, perhaps. Discoverable and portable? [Dongwon] We thought about doing the multi monitor mapping similar to how virt-viewer is doing it but we chose monitor labels because they uniquely identify the monitors even if they are repeatedly unplugged/plugged which may not be possible if we use integer IDs to represent monitors. For example, if virt-viewer client identifies a DP-1 with monitor ID 1 and a HDMI-1 with ID 2 and they are both unplugged and HDMI-1 is hotplugged first, I don't think it would probably ID 1 with HDMI-1 as there is no way for it to know without the label. [Marc-André] Interesting case that could be added to virt-viewer if it's necessary. [Dongwon] The implementation might become very complex if we were to add the "hotplug" functionality as opposed to the simplicity with which it is done with Qemu GTK UI. And, it appears there is no flexibility to make policy changes such as using monitor labels instead of monitor IDs. And, btw, from a quick look, virt-viewer appears to use the same API(gtk_window_move()) that we are relying on, so I guess a similar fate awaits it if Xorg is gone or it switches to GTK4. [Marc-André] Honestly, I don't support the idea of duplicating this effort in QEMU. [Dongwon] That is unfortunate. It is a similar, but a different feature with "hotplug" and labels as its core as described earlier. I think it may not be a great idea to force users who are already using Qemu GTK UI given their use-cases, to use virt-viewer (which adds another layer of complexity) just to use this feature. [Dongwon] Thanks! On 6/14/2024 1:41 AM, Marc-André Lureau wrote: > Hi > > On Thu, Jun 13, 2024 at 9:08 PM Kim, Dongwon <dongwon.kim@intel.com > <mailto:dongwon.kim@intel.com>> wrote: > > > "hotplug" functionality where a Guest display/window is > deeply tied to a > > physical monitor to make it appear to the guest that it is > dealing with > > a real physical monitor. > > > > In other words, when the physical monitor is unplugged, the > associated > > guest display/window gets destroyed/hidden and gets > recreated/shown > > when > > the monitor is hotplugged again. > > > > > > Interesting case that could be added to virt-viewer if it's > necessary. > > > > The subject is sufficiently complex that there is already additional > > documentation/specification in: > > > https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads <https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads> <https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads <https://gitlab.com/virt-viewer/virt-viewer/-/tree/master/docs?ref_type=heads>> > > > > Honestly, I don't support the idea of duplicating this effort in > QEMU. > > Marc-André, > > My assumption is virt-viewer might not be able to completely replace > GTK-UI path in terms of performance and smoothness of display update as > (I think) frame copy between processes is implied, which is same as > > > There is no frame copy when using DMABUF scanouts between qemu and client. > Iow, the performance difference is negligible / noise level. > > spice-remote viewer. What about display-bus that you have been working > on? Would it be a good alternative w.r.t perf concern that I specified > above? > > > There shouldn't be much difference for the local DMABUF display case. > > > > > > -- > > Marc-André Lureau > > > > -- > Marc-André Lureau
© 2016 - 2024 Red Hat, Inc.