Weston window move to second monitor

[Alexandros Frantzis]

On Sun, Oct 02, 2022 at 09:13:27AM +0100, Terry Barnaby wrote:
> Hi,
> 
> I am developing software for an instrument embedded system using NXP CPU's
> and the Wayland/Weston GUI system.
> 
> The hardware platform has a main LCD panel and an optional plug-in HDMI
> monitor. The GUI is currently running with the Weston kiosk-shell and a
> single application is shown full screen on the LCD. Weston is configured so
> that the HDMI monitor appears to the right of the LCD screen and if the
> desktop-shell is used applications can be dragged across.
> 
> Now what I would like is for the application to be moved to the HDMI
> monitor/screen when the monitor is plugged in (resizing as needed).
> 
> With X11 I would have simply, from the application, moved its top level
> window coordinates and without a window manager or with a simple window
> manager the window would move to the area of the second screen.
> 
> Now I understand that Weston and the standard Wayland protocol's do not even
> allow a window move request to be made.
> 
> So I assume I might have to implement a whole new Weston shell, perhaps
> based on the kiosk-shell, and either invent some form of protocol to allow
> the application to request the shell to move it or get the shell to see HDMI
> plug in events and move the application and tell it to resize.
> 
> I don't have much knowledge of Wayland/Weston internals (lots of X11), so
> can anyone give me any pointers on how I might achieve this in the
> simplest/quickest way ?
> 
> Terry

Hi Terry,

Assuming you only care about the fullscreen case, an application can
request (but not force) a fullscreen placement for a toplevel surface
with:

xdg_toplevel_set_fullscreen(xdg_toplevel, wl_output)

In your application you could listen for advertised wl_output globals
and issue a set_fullscreen request for the preferred wl_output (e.g.,
based on the wl_output/xdg_output name). Since you are only dealing with
a specific compositor under your control, you can be fairly confident
that you will get consistent behavior here, i.e., the compositor will
honor your request.

Note that kiosk-shell provides a mechanism in the .ini file to declare
the placement of applications on specific outputs. However, the output
placement decision is static, made only when the surface is first
created/committed to, not for any subsequent output reconfigurations.
Making this output placement in kiosk-shell work more dynamically
(optionally), with the shell moving the surface to the preferred output,
could possibly be a useful enhancement for some use cases.

HTH,
Alexandros