1. 14 Jan, 2020 1 commit
  2. 22 Nov, 2019 1 commit
  3. 29 Oct, 2019 1 commit
  4. 08 Oct, 2019 1 commit
    • Marvin Schmidt's avatar
      build: glx: Lower gl version to work with libglvnd · e6ef2b12
      Marvin Schmidt authored
      When using mesa with libglvnd support, mesa will no longer install the
      gl, glx, egl pkg-config files but instead let libglvnd provide them.
      libglvnd maintainers decided to change the versioning as it was
      mesa-specific previously. Now the libraries have versions of the API
      they expose[1].
      This causes problems when building the X server:
        checking for glproto >= 1.4.17 gl >= 9.2.0... no
        configure: error: Package requirements (glproto >= 1.4.17 gl >= 9.2.0) were not met:
        Requested 'gl >= 9.2.0' but version of gl is 1.2
      Lower the version requirement to 1.2 to allow building against libglvnd
      provided libraries
      [1] https://github.com/NVIDIA/libglvnd/commit/0dfaea2bcb7cdcc785f95e244223bd004a2d7fba
  5. 02 Oct, 2019 1 commit
  6. 05 Sep, 2019 1 commit
  7. 15 Aug, 2019 2 commits
  8. 20 Jun, 2019 1 commit
  9. 17 Jun, 2019 1 commit
    • Jon Turney's avatar
      hw/xwin: A simpleminded attempt at composition · ebcea16e
      Jon Turney authored
      Rather than drawing the window contents from the shadow framebuffer, use
      Composite extension redirection to cause the server to maintain a bitmap
      image of each top-level X window, and draw the window contents from
      that, so that window contents which are occluded in the framebuffer show
      correctly in the task bar and task switcher previews.
      Fix incorrect use of memset() found by gcc5
      hw/xwin/winshadgdi.c: In function ‘winBltExposedWindowRegionShadowGDI’:
      hw/xwin/winshadgdi.c:861:9: warning: ‘memset’ used with constant zero length parameter; this could be due to transposed parameters [-Wmemset-transposed-args]
      Turn on -compositewm by default
      Ignore -swcursor if -compositewm
      -swcursor is not compatible with -compositewm (because the window
      contents are drawn from an off-screen pixmap, not from the screen
      pixmap, where the software cursor will be drawn).
      Update meson.build also
      Add -compositewm option to help output
      Update CI to install prerequisites
  10. 18 May, 2019 2 commits
    • Jon Turney's avatar
      configure: Check for sigprocmask · 7b4b030d
      Jon Turney authored
      MinGW defines SIG_BLOCK, but doesn't have signal masks, so rather than
      checking for SIG_BLOCK, add a configure check for sigprocmask.
      Also add check to meson.build
    • Jon Turney's avatar
      configure: Force --disable-input-thread for MinGW · 246b729d
      Jon Turney authored
      I don't think an input thread can ever be useful on Windows.
      There is a pthread emulation, so having the thread itself isn't much of
      a problem.
      However, there is no device to wait on for Windows events, and even if
      we were to replace select() with WFMO, Windows wants to send events for
      a window to the thread which created that window.
      So, disable input thread by default for MinGW
      Also add similar to meson.build
  11. 02 May, 2019 1 commit
  12. 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
      Remove rootless include paths
      Remove windowswmproto from meson.build
  13. 14 Feb, 2019 1 commit
  14. 16 Jan, 2019 1 commit
  15. 25 Nov, 2018 1 commit
  16. 19 Sep, 2018 2 commits
  17. 09 Aug, 2018 1 commit
  18. 02 Aug, 2018 2 commits
  19. 27 Jun, 2018 1 commit
  20. 11 Jun, 2018 1 commit
  21. 14 May, 2018 1 commit
  22. 10 May, 2018 1 commit
  23. 24 Apr, 2018 3 commits
    • Adam Jackson's avatar
      xserver 1.20 RC5 · c6ab2102
      Adam Jackson authored
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • 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
      - 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
      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>
    • Lyude Paul's avatar
      xwayland: Add xwayland-config.h · 994f7810
      Lyude Paul authored
      Just a small autogenerated header that will soon contain more then just
      one macro.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  24. 12 Apr, 2018 1 commit
  25. 10 Apr, 2018 1 commit
  26. 05 Apr, 2018 1 commit
  27. 02 Apr, 2018 1 commit
  28. 28 Mar, 2018 2 commits
  29. 27 Mar, 2018 1 commit
  30. 21 Mar, 2018 2 commits
  31. 05 Mar, 2018 2 commits