1. 02 May, 2019 3 commits
    • Jon Turney's avatar
      meson: Convert xquartz from autotools · 655b1eb3
      Jon Turney authored
      Differences from autotools:
      
      * Autotools defined NO_ALLOCA for OSX builds.  I don't think we need
      this anymore as Xalloc.h is no longer used anywhere in the xserver.
      
      * X11.bin is linked with -u,miDCInitialize, and then libserver_mi
      provided to satisfy (just) that.  It's been that way since the commit
      which added it.  We can't write the equivalent in meson due to linker
      argument ordering issues, but do we really need to?
      
      * An explicit -Dsecure-rpc=false is required for OSX, since in meson we
      don't do the checks that XTRANS_SECURE_RPC_FLAGS did for the existence
      of the specific RPC functions required.
      655b1eb3
    • Jon Turney's avatar
      meson: Build rootless extension · ecf62b7b
      Jon Turney authored
      ecf62b7b
    • Jon Turney's avatar
      Promote file containing date & time build was configured to top-level · b4ed20c4
      Jon Turney authored
      Promote the generated file containing the date & time build was
      configured to top-level.
      
      Rename it from xf86Build.h to buildDateTIme.h.
      
      Use it as well in XQuartz, stringize BUILD_DATE when needed.
      b4ed20c4
  2. 01 May, 2019 1 commit
    • Jon Turney's avatar
      hw/xwin: Remove mwextwm mode · a2302de6
      Jon Turney authored
      This has always been described as 'experimental'
      
      We don't think this has any users: This mode has been disabled in Cygwin
      packages since March 2016. We've never provided the xwinwm WM for x86_64
      Cygwin. No one has even asked where the option has gone.
      
      This leaves XQuartz as the only user of the rootless extension.
      
      Remove --enable-windowswm configure option
      Remove multiwindowextwm stuff from Makefiles
      Remove -mwextwm option
      Remove -mwextwm from man-page and help
      Un-ifdef XWIN_MULTIWINDOWEXTWM
      
      v2:
      Remove rootless include paths
      Remove windowswmproto from meson.build
      a2302de6
  3. 30 Apr, 2019 2 commits
  4. 20 Mar, 2019 1 commit
    • Jon Turney's avatar
      meson: handle missing xkbcomp.pc better · f3567600
      Jon Turney authored
      Applying get_pkgconfig_variable() to a not-found dependency was always
      documented as an error, but meson 0.49 now actually raises an error[1]:
      
        meson.build:110:4: ERROR:  'xkbcomp' is not a pkgconfig dependency
      
      Check xkbcomp_dep is a suitable dependency type before applying
      get_pkgconfig_variable() to it.
      
      [1] but this is more by accident than design (see the discusssion at [2]
      et seq.), so who knows where things will come to rest...
      
      [2] https://github.com/mesonbuild/meson/pull/4444#issuecomment-442443301
      f3567600
  5. 05 Mar, 2019 1 commit
    • Adam Jackson's avatar
      meson: Bump required meson version to 0.46 · 7e046b94
      Adam Jackson authored
      We were being naughty:
      
      WARNING: Project specifies a minimum meson_version '>= 0.42.0' but uses features which were added in newer versions:
       * 0.46.0: {'compiler.has_multi_link_argument', 'compiler.has_link_argument'}
      7e046b94
  6. 06 Sep, 2018 1 commit
    • Lyude Paul's avatar
      meson: Fix building with -Ddga=false · b84e7f1c
      Lyude Paul authored
      We forget to assign a value to xf86dgaproto_dep if -Ddga=false, which
      causes the meson build to fail:
      
      meson.build:448:0: ERROR:  Unknown variable "xf86dgaproto_dep".
      
      A full log can be found at /home/lyudess/build/xserver/meson-logs/meson-log.txt
      FAILED: build.ninja
      
      So, just set it to an empty dependency to fix that.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      b84e7f1c
  7. 28 Aug, 2018 1 commit
  8. 09 Aug, 2018 2 commits
  9. 01 Jul, 2018 1 commit
  10. 14 May, 2018 2 commits
  11. 10 May, 2018 1 commit
  12. 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: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      b6bf68b8
  13. 30 Apr, 2018 1 commit
  14. 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: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      54ac0971
  15. 19 Apr, 2018 1 commit
    • Lyude Paul's avatar
      meson: Ensure we always build Xext/hashtable.c for glx · 4e28a6a2
      Lyude Paul authored
      Seems that while glxvnd relies on some of the hashtable functions in
      Xext, we only build hashtable support for Xext if we're also building
      the res extension. This leads to some errors if you try to build glx
      without res enabled:
      
      glx/liblibglxvnd.a(vndcmds.c.o): In function `LookupVendorPrivDispatch':
      /home/lyudess/Projects/xserver/glx/vndcmds.c:65: undefined reference to `ht_find'
      /home/lyudess/Projects/xserver/glx/vndcmds.c:67: undefined reference to `ht_add'
      glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchInit':
      /home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to `ht_generic_compare'
      /home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to `ht_generic_hash'
      /home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to `ht_create'
      glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchReset':
      /home/lyudess/Projects/xserver/glx/vndcmds.c:468: undefined reference to `ht_destroy'
      collect2: error: ld returned 1 exit status
      ninja: build stopped: subcommand failed.
      
      So, make sure that hashtable.c gets both for both glx and res
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      4e28a6a2
  16. 10 Apr, 2018 1 commit
  17. 02 Apr, 2018 3 commits
    • Adam Jackson's avatar
      xserver 1.20 RC3 · df6cbf7a
      Adam Jackson authored
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      df6cbf7a
    • Thierry Reding's avatar
      meson: Add pixman-1 to required modules in xorg-server.pc · 80d40984
      Thierry Reding authored
      pixman headers will be included for builds of external modules against
      the xorg-server SDK. Make sure pixman is listed as a required module so
      that the correct CFLAGS will be added.
      
      Note that the xorg-server.pc generated by the autotools-based build has
      many more modules listed, but this seems to be enough to build at least
      some of the external drivers against an X server built with Meson (I've
      tested with xf86-input-libinput, xf86-video-nouveau and xf86-video-ati).
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      80d40984
    • Thierry Reding's avatar
      meson: Remove usage of pkg-config --variable=includedir · f3b0a2ae
      Thierry Reding authored
      Querying a pkg-config variable using the --variable option produces the
      value of the given variable as stored in the pkg-config file and should
      not be used to add directories to the include search path.
      
      The reason for this is that it breaks cross-compilation, because header
      files are installed relative to the host sysroot. pkg-config supports a
      PKG_CONFIG_SYSROOT_DIR environment variable that points to this sysroot
      and will prepend that to the path of directories in -I or -L options in
      pkg-config's Cflags, Libs or Libs.private keywords. However, because no
      context can be inferred from variable names, as opposed to the keywords
      with fixed meaning, the sysroot path will not be prepended to them. The
      build system is responsible for doing so if necessary since it is aware
      of the context in which the variable is used.
      
      Adding the include directory returned by pkg-config to the include path
      leaks build system information into the cross-build and break with very
      confusing errors such as this:
      
      	In file included from include/misc.h:82:0,
      			 from dix/atom.c:55:
      	/usr/include/pthread.h:682:6: warning: '__regparm__' attribute directive ignored [-Wattributes]
      	      __cleanup_fct_attribute;
      	      ^~~~~~~~~~~~~~~~~~~~~~~
      
      or this:
      
      	In file included from include/misc.h:139:0,
      			 from dix/atom.c:55:
      	/usr/include/stdlib.h:133:8: error: '_Float128' is not supported on this target
      	 extern _Float128 strtof128 (const char *__restrict __nptr,
      		^~~~~~~~~
      
      Fix this by replacing the include directory with the appropriate xproto
      dependency required to add the correct include directory to the compile
      command for subdirectories that are missing the dependency. As detailed
      above, this gives pkg-config the opportunity to prepend the sysroot for
      all paths in -I compiler options.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      f3b0a2ae
  18. 28 Mar, 2018 4 commits
  19. 27 Mar, 2018 7 commits
  20. 21 Mar, 2018 1 commit
  21. 09 Mar, 2018 1 commit
  22. 05 Mar, 2018 3 commits