1. 17 Mar, 2017 2 commits
    • Adam Jackson's avatar
      xfree86: Remove 24bpp pixmap format support (v2) · e33be78e
      Adam Jackson authored
      There's really no reason to pretend to support this, apps hate it, all
      we're doing is giving people a way to injure themselves. It doesn't work
      anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810.
      Rip out all the logic for handling 24bpp pixmaps and framebuffers, and
      silently ignore the old options that would ask for it.
      
      The cirrus alpine driver has been updated to default to 16bpp, and both
      it and the i810 driver can now use the 32->24 conversion code in shadow
      if they want. All other drivers support 32bpp. Configurations that
      explicitly request 24bpp in order to fit in VRAM will be broken now
      though.
      
      v2: Fix command line options to silently ignore 24bpp rather than fail
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      e33be78e
    • Adam Jackson's avatar
      ephyr: Don't clobber bitsPerPixel when using glamor · 83c4297d
      Adam Jackson authored
      This ends up passing 0 as the bpp argument to fb screen setup, which is
      not really the best plan.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      83c4297d
  2. 16 Mar, 2017 2 commits
  3. 15 Mar, 2017 6 commits
  4. 14 Mar, 2017 2 commits
    • Adam Jackson's avatar
      test: Fix distcheck failures · 646bc74c
      Adam Jackson authored
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      646bc74c
    • Jon Turney's avatar
      xfree86: work around a sdksyms problem with gcc5 on Cygwin · bca22160
      Jon Turney authored
      The linemarkers in the preprocessor output from gcc5 on Cygwin have
      canonicalized paths to included files (e.g. xserver/build/../include/misc.h
      is canonicalized to xserver/build/include/misc.h). (see gcc svn rev 210264,
      which causes the transformation performed by -fcanonical-system-headers to
      be applied to all include pathnames)
      
      These canonicalized paths won't match $topdir, so sdksyms doesn't look at
      the contents of those headers for sdk exported symbols.
      
      Workaround this by canonicalizing all the paths we consider, using readlink.
      
      v2:
      Keep a cache of readlink results so it isn't quite so dreadfully slow.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      bca22160
  5. 13 Mar, 2017 1 commit
    • Tobias Stoeckmann's avatar
      render: Fix out of boundary heap access · ac15d4ce
      Tobias Stoeckmann authored
      ProcRenderCreateRadialGradient and ProcRenderCreateConicalGradient must
      be protected against an integer overflow during length check. This is
      already included in ProcRenderCreateLinearGradient since the fix for
      CVE-2008-2362.
      
      This can only be successfully exploited on a 32 bit system for an
      out of boundary read later on. Validated by using ASAN.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      ac15d4ce
  6. 09 Mar, 2017 3 commits
  7. 07 Mar, 2017 2 commits
  8. 06 Mar, 2017 1 commit
  9. 02 Mar, 2017 4 commits
  10. 01 Mar, 2017 8 commits
  11. 28 Feb, 2017 4 commits
  12. 26 Feb, 2017 1 commit
  13. 23 Feb, 2017 4 commits
    • Olivier Fourdan's avatar
      Revert "xwayland: bump wayland-protocols version to 1.7" · 7d7788e0
      Olivier Fourdan authored
      This reverts commit 371ff0c9.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      7d7788e0
    • Pekka Paalanen's avatar
      xwayland: use _XWAYLAND_ALLOW_COMMITS property · 9f4d308c
      Pekka Paalanen authored
      The X11 window manager (XWM) of a Wayland compositor can use the
      _XWAYLAND_ALLOW_COMMITS property to control when Xwayland sends
      wl_surface.commit requests. If the property is not set, the behaviour
      remains what it was.
      
      XWM uses the property to inhibit commits until the window is ready to be
      shown. This gives XWM time to set up the window decorations and internal
      state before Xwayland does the first commit. XWM can use this to ensure
      the first commit carries fully drawn decorations and the window
      management state is correct when the window becomes visible.
      
      Setting the property to zero inhibits further commits, and setting it to
      non-zero allows commits. Deleting the property allows commits.
      
      When the property is changed from zero to non-zero, there will be a
      commit on next block_handler() call provided that some damage has been
      recorded.
      
      Without this patch (i.e. with the old behaviour) Xwayland can and will
      commit the surface very soon as the application window has been realized
      and drawn into.  This races with XWM and may cause visible glitches.
      
      v3:
      - introduced a simple setter for xwl_window::allow_commits
      - split xwl_window_property_allow_commits() out of
        xwl_property_callback()
      - check MakeAtom(_XWAYLAND_ALLOW_COMMITS)
      
      v2:
      - use PropertyStateCallback instead of XACE, based on the patch
        "xwayland: Track per-window support for netwm frame sync" by
        Adam Jackson
      - check property type is XA_CARDINAL
      - drop a useless memcpy()
      
      Weston Bug: https://phabricator.freedesktop.org/T7622Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      9f4d308c
    • Pekka Paalanen's avatar
      xwayland: fix 'buffer' may be used uninitialized warning · a6308cea
      Pekka Paalanen authored
      Fix the following warning due to --disable-glamor:
      
        CC       Xwayland-xwayland.o
      In file included from /home/pq/local/include/wayland-client.h:40:0,
                       from xwayland.h:35,
                       from xwayland.c:26:
      xwayland.c: In function ‘block_handler’:
      /home/pq/local/include/wayland-client-protocol.h:3446:2: warning: ‘buffer’ may be used uninitialized in this function [-Wmaybe-uninitialized]
        wl_proxy_marshal((struct wl_proxy *) wl_surface,
        ^
      xwayland.c:466:23: note: ‘buffer’ was declared here
           struct wl_buffer *buffer;
                             ^
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      a6308cea
    • Pekka Paalanen's avatar
      xwayland: refactor into xwl_window_post_damage() · f7b8560f
      Pekka Paalanen authored
      Refactor xwl_screen_post_damage() and split the window specific code
      into a new function xwl_window_post_damage().
      
      This is a pure refactoring, there are no behavioral changes. An assert
      is added to xwl_window_post_damage() to ensure frame callbacks are not
      leaked if a future patch changes the call.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      f7b8560f