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....@intel.com
<mailto:dongwon....@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....@intel.com <mailto:dongwon....@intel.com>
> <mailto:dongwon....@intel.com <mailto:dongwon....@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....@intel.com <mailto:dongwon....@intel.com>
<mailto:dongwon....@intel.com <mailto:dongwon....@intel.com>>
> > <mailto:dongwon....@intel.com
<mailto:dongwon....@intel.com> <mailto:dongwon....@intel.com
<mailto:dongwon....@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
