GNOME Bugzilla – Bug 772525
mutter ignores the wl_output parameter to set_fullscreen in both wl_shell and zxdg_shell_v6 protocols
Last modified: 2017-02-21 19:02:42 UTC
Both wl_shell_surface_set_fullscreen (wl_shell) and xdg_toplevel_set_fullscreen (zxdg_shell_v6) ignore their struct wl_resource *output_resource parameter, and with it any clients' requests to be fullscreened on a certain output.
Created attachment 338968 [details] [review] wayland-xdg-shell: Handle the wl_output on the set_fullscreen request This makes us fullscreen wayland windows on the requested monitor.
Created attachment 338977 [details] [review] wayland-xdg-shell: Handle the wl_output on the set_fullscreen request -- I just noticed in the protocol that the wl_output may be NULL so updated the patch accordingly.
Created attachment 339940 [details] [review] window: Make move_to_monitor work for zero sized and offscreen windows Wayland windows are initially zero sized until clients commit the first buffer. Despite being invisible, clients are allowed to request such windows to be fullscreened on a specific output before they attach the first buffer which means we need to be able to move them. meta_window_move_to_monitor() doesn't handle this case because these windows' initial monitor is a placeholder since their initial coordinates are 0,0+0+0, which results in us using a rectangle as old_area for meta_window_move_between_rects() that might be to the "right" of the window causing the move to go further out of the visible screen's coordinates. This is later "corrected" by the constraints system but the window might end up in the wrong monitor. To fix this, we can make meta_window_move_between_rects() accept a NULL old_area, meaning that we move the window to the new_area without trying to keep a relative position. -- The previous patch isn't enough with some output geometries. This and the next patch should fix it.
Created attachment 339941 [details] [review] constraints: Make zero sized windows be placed in the correct monitor Wayland windows can be zero sized until clients attach a buffer, but our rectangle code doesn't deal with this case well, in particular, meta_screen_get_monitor_for_rect() might end up choosing the wrong monitor for a zero sized rectangle since meta_rectangle_contains_rect() considers a zero sized rectangle at the right or bottom edges of another rectangle (the monitor's) to be contained there. Since out size limits constraint will enforce a minimum size of 1x1, we might as well enforce that when setting up the constraint info so that the correct monitor gets chosen and the single monitor constraint doesn't move these windows to the wrong one. -- Alternatively we could fix the boxes.c code to handle zero sized rectangles better, but I'm not sure we could determine what "better" means generically at that level.
Review of attachment 338977 [details] [review]: Looks good to me.
Review of attachment 339940 [details] [review]: Looks good to me.
Review of attachment 339941 [details] [review]: Looks good to me.
Attachment 338977 [details] pushed as 1fe10f0 - wayland-xdg-shell: Handle the wl_output on the set_fullscreen request Attachment 339940 [details] pushed as bb2e8ff - window: Make move_to_monitor work for zero sized and offscreen windows Attachment 339941 [details] pushed as 8f5a0ec - constraints: Make zero sized windows be placed in the correct monitor