1. 09 May, 2018 1 commit
    • Aaron Plattner's avatar
      meson: Fix module_dir configuration (v2) · b6bf68b8
      Aaron Plattner authored
      meson.build has code to set the module_dir variable to
      ${libdir}/xorg/modules if the module_dir option string is empty.
      However, this has several problems:
      
      1. The variable is only used for an unused @moduledir@ substitution in
         the man page. The rule for xorg-server.pc uses option('module_dir')
         directly instead.
      2. The 'module_dir' option has a default value of 'xorg/modules' so the
         above rule doesn't do anything by default.
      3. The xorg-server.pc rule uses ${exec_prefix}/option('module_dir'), so
         the effect of #2 is that the default moduledir is different between
         autoconf and meson. E.g. if ${prefix} is /X, then you get
      
           autoconf: moduledir=/X/lib/xorg/modules
           meson:    moduledir=/X/xorg/modules
      
      Fix this by using the module_dir variable when generating xorg-server.pc, and by
      using join_paths() to assign module_dir unconditionally.
      
      v2: Keep the 'xorg/modules' default path, but use join_paths() unconditionally (Thierry Reding)
      Signed-off-by: 's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      b6bf68b8
  2. 24 Apr, 2018 1 commit
    • Lyude Paul's avatar
      xwayland: Add glamor egl_backend for EGLStreams · 54ac0971
      Lyude Paul authored
      This adds initial support for displaying Xwayland applications through
      the use of EGLStreams and nvidia's custom wayland protocol by adding
      another egl_backend driver. This also adds some additional egl_backend
      hooks that are required to make things work properly.
      
      EGLStreams work a lot differently then the traditional way of handling
      buffers with wayland. Unfortunately, there are also a LOT of various
      pitfalls baked into it's design that need to be explained.
      
      This has a very large and unfortunate implication: direct rendering is,
      for the time being at least, impossible to do through EGLStreams. The
      main reason being that the EGLStream spec mandates that we lose the
      entire color buffer contents with each eglSwapBuffers(), which goes
      against X's requirement of not losing data with pixmaps.  no way to use
      an allocated EGLSurface as the storage for glamor rendering like we do
      with GBM, we have to rely on blitting each pixmap to it's respective
      EGLSurface producer each frame. In order to pull this off, we add two
      different additional egl_backend hooks that GBM opts out of
      implementing:
      
      - egl_backend.allow_commits for holding off displaying any EGLStream
        backed pixmaps until the point where it's stream is completely
        initialized and ready for use
      - egl_backend.post_damage for blitting the content of the EGLStream
        surface producer before Xwayland actually damages and commits the
        wl_surface to the screen.
      
      The other big pitfall here is that using nvidia's wayland-eglstreams
      helper library is also not possible for the most part. All of it's API
      for creating and destroying streams rely on being able to perform a
      roundtrip in order to bring each stream to completion since the wayland
      compositor must perform it's job of connecting a consumer to each
      EGLstream. Because Xwayland has to potentially handle both responding to
      the wayland compositor and it's own X clients, the situation of the
      wayland compositor being one of our X clients must be considered. If we
      perform a roundtrip with the Wayland compositor, it's possible that the
      wayland compositor might currently be connected to us as an X client and
      thus hang while both Xwayland and the wayland compositor await responses
      from eachother. To avoid this, we work directly with the wayland
      protocol and use wl_display_sync() events along with release() events to
      set up and destroy EGLStreams asynchronously alongside handling X
      clients.
      
      Additionally, since setting up EGLStreams is not an atomic operation we
      have to take into consideration the fact that an EGLStream can
      potentially be created in response to a window resize, then immediately
      deleted due to another pending window resize in the same X client's
      pending reqests before Xwayland hits the part of it's event loop where
      we read from the wayland compositor. To make this even more painful, we
      also have to take into consideration that since EGLStreams are not
      atomic that it's possible we could delete wayland resources for an
      EGLStream before the compositor even finishes using them and thus run
      into errors. So, we use quite a bit of tracking logic to keep EGLStream
      objects alive until we know the compositor isn't using them (even if
      this means the stream outlives the pixmap it backed).
      
      While the default backend for glamor remains GBM, this patch exists for
      users who have had to deal with the reprecussion of their GPU
      manufacturers ignoring the advice of upstream and the standardization of
      GBM across most major GPU manufacturers. It is not intended to be a
      final solution to the GBM debate, but merely a baindaid so our users
      don't have to suffer from the consequences of companies avoiding working
      upstream. New drivers are strongly encouraged not to use this as a
      backend, and use GBM like everyone else. We even spit this out as an
      error from Xwayland when using the eglstream backend.
      Signed-off-by: 's avatarLyude Paul <lyude@redhat.com>
      Acked-by: 's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: 's avatarAdam Jackson <ajax@redhat.com>
      54ac0971
  3. 28 Mar, 2018 1 commit
  4. 27 Mar, 2018 2 commits
  5. 02 Mar, 2018 3 commits
  6. 19 Feb, 2018 2 commits
  7. 14 Feb, 2018 3 commits
  8. 16 Jan, 2018 1 commit
  9. 25 Oct, 2017 1 commit
  10. 12 Oct, 2017 1 commit
    • Lyude Paul's avatar
      meson: Add xkb_bin_dir option · 10cba7d5
      Lyude Paul authored
      Now that we can actually configure all of the directories xkb uses for
      finding things, we can (finally, but only with meson) finally make it so
      that with the correct meson configuration the Xserver will "just work"
      without any additional changes to the installation prefix after
      building.
      
      For the people like me who have since scripted this part out of their
      build process and forgotten about it, building and installing the X
      server into a non-standard prefix has always required the following (or
      something else that makes sure that X has a valid xkbcomp configuration)
      commands be run right after doing the installation:
      
      	# start in root of prefix you installed X to
      	mkdir -pv share/X11/xkb/rules
      	ln -s /usr/share/X11/xkb/rules/evdev share/X11/xkb/rules/
      	rm -f bin/xkbcomp
      	ln -s /usr/bin/xkbcomp bin/
      
      The one last piece of getting rid of this post-install junk is making
      sure that we can control the directory that X uses for finding the
      xkbcomp binary from meson so we can point it at the system provided
      xkbcomp (/usr/bin/xkbcomp or similar). So, this patch adds a
      configuration option for controlling this called xkb_bin_dir.
      Signed-off-by: 's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: 's avatarDaniel Stone <daniels@collabora.com>
      10cba7d5
  11. 20 Sep, 2017 1 commit
  12. 20 Jun, 2017 1 commit
  13. 02 Jun, 2017 1 commit
  14. 10 May, 2017 1 commit
  15. 04 May, 2017 1 commit
  16. 26 Apr, 2017 1 commit
    • Eric Anholt's avatar
      Add a Meson build system alongside autotools. · 1549e303
      Eric Anholt authored
      This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
      and Xdmx so far.  The outline of Xquartz/Xwin support is in tree, but
      hasn't been built yet.  The unit tests are also not done.
      
      The intent is to build this as a complete replacement for the
      autotools system, then eventually replace autotools.  meson is faster
      to generate the build, faster to run the bulid, shorter to write the
      build files in, and less error-prone than autotools.
      
      v2: Fix indentation nits, move version declaration to project(), use
          existing meson_options for version-config.h's vendor name/web.
      Signed-off-by: 's avatarEric Anholt <eric@anholt.net>
      Acked-by: 's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      1549e303