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
