1. 07 Jul, 2020 1 commit
  2. 03 Jul, 2020 1 commit
    • Olivier Fourdan's avatar
      xwayland: Use a fixed DPI value for core protocol · b0413b6e
      Olivier Fourdan authored and Michel Dänzer's avatar Michel Dänzer committed
      
      
      The way Xwayland works (like all Wayland clients), it first queries the
      Wayland registry, set up all relevant protocols and then initializes its
      own structures.
      
      That means Xwayland will get the Wayland outputs from the Wayland
      compositor, compute the physical size of the combined outputs and set
      the corresponding Xwayland screen properties accordingly.
      
      Then it creates the X11 screen using fbScreenInit() but does so by using
      a default DPI value of 96. That value is used to set the physical size
      of the X11 screen, hence overriding the value computed from the actual
      physical size provided by the Wayland compositor.
      
      As a result, the DPI computed by tools such as xdpyinfo will always be
      96 regardless of the actual screen size and resolution.
      
      However, if the Wayland outputs get reconfigured, or new outputs added,
      or existing outputs removed, Xwayland will recompute and update the
      physical size of the screen, leading to an unexpected change of DPI.
      
      To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can
      be set using the standard command lime option "-dpi") and compute a
      physical screen size to match that DPI setting.
      
      Note that only affects legacy core protocols, X11 clients can still get
      the actual physical output size as reported by the Wayland compositor
      using the RandR protocol, which also allows for the size to be 0 if the
      size is unknown or meaningless.
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      Closes: xorg/xserver#731
      b0413b6e
  3. 13 May, 2020 1 commit
    • Carlos Garnacho's avatar
      xwayland: Improve checks for confined_to on InputOnly windows · 0777cf46
      Carlos Garnacho authored and Olivier Fourdan's avatar Olivier Fourdan committed
      
      
      In this pretty Wine/Proton specific kludge, we try to handle confining grabs
      on InputOnly windows by trying to find the InputOutput window that the pointer
      would get visually confined to.
      
      The grabbing window and the visible window come from different clients, so
      we used to simply resort to the pointer focus. This is troublesome though, as
      the call may happen very soon at a time that the toplevel wasn't yet mapped by
      the Wayland compositor, so the pointer focus may well be out of date soon.
      
      In these situations, it does seem that even though the confining grab happens
      too early to have the wayland surface mapped, the xserver view of the WindowPtr
      does already reflect the size. Use this to find out the better window to
      assign the confining grab to, one whose geometry fully contains the InputOnly
      window's.
      
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      Reviewed-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      0777cf46
  4. 27 Apr, 2020 1 commit
    • Olivier Fourdan's avatar
      xwayland: Fix infinite loop at startup · 785e5906
      Olivier Fourdan authored
      
      
      Mutter recently added headless tests, and when running those tests the
      Wayland compositor runs for a very short time.
      
      Xwayland is spawned by the Wayland compositor and upon startup will
      query the various Wayland protocol supported by the compositor.
      
      To do so, it will do a roundtrip to the Wayland server waiting for
      events it expects.
      
      If the Wayland compositor terminates before Xwayland has got the replies
      it expects, it will loop indefinitely calling `wl_display_roundtrip()`
      continuously.
      
      To avoid that issue, add a new `xwl_screen_roundtrip()` that checks for
      the returned value from `wl_display_roundtrip()` and fails if it is
      negative.
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      785e5906
  5. 28 Feb, 2020 1 commit
  6. 23 Feb, 2020 2 commits
    • Hans de Goede's avatar
      xwayland: Also hook screen's MoveWindow method · 10df0437
      Hans de Goede authored
      
      
      Not only hook the ResizeWindow method of the screen (which really is
      MoveAndResize) but also hook the MoveWindow method for checking if we
      need to setup a viewport for resolution change emulation.
      
      Our resolution change emulation check if the windows origin matches
      the monitors origin and the windows origin can also be changed by just
      a move without being resized.
      
      Also checking on a move becomes esp. important when we move to checking
      on changes to the top-level non-window-manager client (X11)Window instead
      of on changes to the xwl_window later on in this patch series.
      
      Acked-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      10df0437
    • Hans de Goede's avatar
      xwayland: Cache client-id for the window-manager client · ded89300
      Hans de Goede authored
      
      
      Instead of iterating over all clients which are listening for events on the
      root window and checking if the client we are dealing with is the one
      listening for SubstructureRedirectMask | ResizeRedirectMask events and thus
      is the window-manager, cache the client-id of the window-manager in
      xwl_screen and use that when checking if a client is the window-manager.
      
      Note that we cache and compare the client-id rather then the ClienPtr,
      this saves reading the ClientPtr from the global clients array when doing
      the comparison.
      
      Suggested-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Acked-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      ded89300
  7. 11 Feb, 2020 2 commits
  8. 20 Dec, 2019 10 commits
  9. 17 Dec, 2019 1 commit
  10. 13 Dec, 2019 3 commits
  11. 28 Nov, 2019 2 commits
    • Olivier Fourdan's avatar
      xwayland: Use multiple window buffers · cd999f08
      Olivier Fourdan authored
      Xwayland takes care of not attaching a new buffer if a frame callback is
      pending.
      
      Yet, the existing buffer (which was previously attached) may still be
      updated from the X11 side, causing unexpected visual glitches to the
      buffer.
      
      Add multiple buffering to the xwl_window and alternate between buffers,
      to leave the Wayland buffer untouched between frame callbacks and avoid
      stuttering or tearing issues.
      
      Closes: xorg/xserver#835
      
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      cd999f08
    • Olivier Fourdan's avatar
      xwayland: Add buffer release callback · 77658741
      Olivier Fourdan authored
      
      
      The API `wl_buffer_add_listener` is misleading in the sense that there
      can be only one `wl_buffer` release callback, and trying to add a new
      listener when once is already in place will lead to a protocol error.
      
      The Xwayland EGL backends may need to set up their own `wl_buffer`
      release listener, meaning that there is no way to our own `wl_buffer`
      release callback.
      
      To avoid the problem, add our own callback API to be notified when the
      `wl_buffer` associated with an `xwl_pixmap` is released, triggered from
      the different `xwl_pixmap` implementations.
      
      Also update the Present code to use the new buffer release callback API.
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      77658741
  12. 19 Nov, 2019 1 commit
    • Olivier Fourdan's avatar
      xwayland: Do not discard frame callbacks on allow commits · 66da95a1
      Olivier Fourdan authored and Olivier Fourdan's avatar Olivier Fourdan committed
      
      
      Currently, when a X11 client (usually the X11 window manager from a
      Wayland compositor) changes the value of the X11 property
      `_XWAYLAND_ALLOW_COMMITS` from `false` to `true`, all pending frame
      callbacks on the window are discarded so that the commit occurs
      immediately.
      
      Weston uses that mechanism to prevent the content of the window from
      showing before it's ready when mapping the window initially, but
      discarding the pending frame callbacks has no effect on the initial
      mapping of the X11 window since at that point there cannot be any frame
      callback on a surface which hasn't been committed yet anyway.
      
      However, discarding pending frame callbacks can be problematic if we
      were to use the same `_XWAYLAND_ALLOW_COMMITS` mechanism to prevent
      damages to be posted before the X11 toplevel is updated completely
      (including the window decorations from the X11 window manager).
      
      Remove the portion of code discarding the pending frame callback,
      Xwayland should always wait for a pending frame callback if there's one
      before posting new damages.
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      xorg/xserver!333
      66da95a1
  13. 12 Oct, 2019 7 commits
  14. 10 Sep, 2019 1 commit
    • Carlos Garnacho's avatar
      xwayland: Allow passing a fd for set up clients · 7ad1d0d3
      Carlos Garnacho authored and Adam Jackson's avatar Adam Jackson committed
      
      
      This FD also triggers the "wait for WM_S0" paths, so that the
      compositor may set up a "maintenance line" for Xwayland, for
      services that are essential to run before any client (eg. xrdb).
      Those services would use this FD, disguised as an extra display
      connection.
      
      This -initfd can be seen as a generalization of -wm, a Wayland
      compositor may use -initfd to launch its WM and any other clients
      that should start up, or it may use -wm as a dedicated connection for
      the WM and optionally use -initfd for the misc. startup clients.
      
      If either of -wm or -initfd is passed, Xwayland will expect a selection
      notification on WM_S0 before incorporating the FDs in -listen to the
      poll list.
      
      Also, correct a minor typo in the listenfd argument output,
      give → given.
      
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      7ad1d0d3
  15. 09 Sep, 2019 1 commit
    • Carlos Garnacho's avatar
      xwayland: Handle the case of windows being realized before redirection · 78cc8b6f
      Carlos Garnacho authored
      
      
      If Xwayland gets to realize a window meant for composition before the
      compositor redirected windows (i.e. redirect mode is not RedirectDrawManual
      yet), the window would stay "invisible" as we wouldn't create a
      wl_surface/wl_shell_surface for it at any later point.
      
      This scenario may happen if the wayland compositor sets up a X11 socket
      upfront, but waits to raise Xwayland until there are X11 clients. In this
      case the first data on the socket is the client's, the compositor can hardly
      beat that in order to redirect subwindows before the client realizes a
      Window.
      
      In order to jump across this hurdle, allow the late creation of a matching
      (shell) surface for the WindowPtr on SetWindowPixmapProc, so it is ensured
      to be created after the compositor set up redirection.
      
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      Reviewed-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      78cc8b6f
  16. 05 Sep, 2019 3 commits
  17. 31 Jul, 2019 1 commit
  18. 19 Jun, 2019 1 commit
    • Olivier Fourdan's avatar
      xwayland: Add "-listenfd" option · b3f3d65e
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      
      
      Using the existing command line option "-listen" for passing file
      descriptors between the Wayland compositor and Xwayland is misleading,
      Xwayland should add is own command line option for that specific use.
      
      As XWayland is spawned by the Wayland compositor, we cannot just change
      the option, as that would break all existing Wayland compositors using
      Xwayland, so we add a new options "-listenfd" and mark the previous one
      as deprecated and log a warning, but it still works for backward
      compatibility.
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      !214
      b3f3d65e