Hi On Thu, Jun 13, 2024 at 3:34 AM Kim, Dongwon <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>> 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>>> > 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
