1. 24 Mar, 2017 1 commit
  2. 23 Mar, 2017 8 commits
  3. 21 Mar, 2017 2 commits
  4. 20 Mar, 2017 4 commits
    • Tobias Stoeckmann's avatar
      record: Fix OOB access in ProcRecordUnregisterClients · 40c12a76
      Tobias Stoeckmann authored
      If a client sends a RecordUnregisterClients request with an nClients
      field larger than INT_MAX / 4, an integer overflow leads to an
      out of boundary access in RecordSanityCheckClientSpecifiers.
      An example line with libXtst would be:
      XRecordUnregisterClients(dpy, rc, clients, 0x40000001);
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • Adam Jackson's avatar
      glamor: Avoid software fallback for planemasked ZPixmap GetImage · 1ad23068
      Adam Jackson authored
      Same trick as in fb: just do a normal GetImage and deal with the
      planemask on the CPU if you have to. Since the software fallback hit for
      glamor is pretty brutal, this is a much more impressive win for glamor
      than it was for fb:
        11100.0  87700.0 (7.901) (copy 0xaaaaaaaa) ShmGetImage 10x10 square
         9840.0  47800.0 (4.858) (copy 0xaaaaaaaa) ShmGetImage 100x100 square
         1550.0   4240.0 (2.735) (copy 0xaaaaaaaa) ShmGetImage 500x500 square
         9450.0  78900.0 (8.349) (0xaaaaaaaa) GetImage 10x10 square
         6910.0  30900.0 (4.472) (0xaaaaaaaa) GetImage 100x100 square
          431.0   2020.0 (4.687) (0xaaaaaaaa) GetImage 500x500 square
      Measured with Xephyr -glamor on Skylake GT3e.
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • Adam Jackson's avatar
      fb: Handle ZPixmap planemask in GetImage the other way around · 4aa35c46
      Adam Jackson authored
      Formerly we'd zero the image data and then pull out a plane at a time.
      It's faster to apply the planemask after the fact, since that turns the
      GetImage into a memcpy:
        100000.0  101000.0 (1.010) (copy 0xaaaaaaaa) ShmGetImage 10x10 square
         42400.0   59400.0 (1.401) (copy 0xaaaaaaaa) ShmGetImage 100x100 square
          3040.0    5280.0 (1.737) (copy 0xaaaaaaaa) ShmGetImage 500x500 square
         96100.0   95200.0 (0.991) (0xaaaaaaaa) GetImage 10x10 square
         29600.0   36800.0 (1.243) (0xaaaaaaaa) GetImage 100x100 square
          1850.0    2620.0 (1.416) (0xaaaaaaaa) GetImage 500x500 square
      Measured with Xvfb at depth 24 on Skylake i7-6560U.
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • Kenneth Graunke's avatar
      dri2: Sync i965_pci_ids.h from Mesa. · 368f60d4
      Kenneth Graunke authored
      Copied from Mesa with no modifications.  Gives us Geminilake PCI IDs.
      Signed-off-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Acked-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
  5. 17 Mar, 2017 4 commits
    • Olivier Fourdan's avatar
      glamor: avoid a crash if texture allocation failed · 8805a48e
      Olivier Fourdan authored
      Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY
      is raised, in which case the texture returned is zero.
      But the texture value is not checked in glamor_create_fbo() and glamor
      will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0:
        Truncated backtrace:
        Thread no. 1 (10 frames)
         #4 glamor_pixmap_ensure_fb at glamor_fbo.c:57
         #5 glamor_create_fbo_from_tex at glamor_fbo.c:112
         #6 glamor_create_fbo at glamor_fbo.c:159
         #7 glamor_create_fbo_array at glamor_fbo.c:210
         #8 glamor_create_pixmap at glamor.c:226
         #9 compNewPixmap at compalloc.c:536
         #10 compAllocPixmap at compalloc.c:605
         #11 compCheckRedirect at compwindow.c:167
         #12 compRealizeWindow at compwindow.c:267
         #13 RealizeTree at window.c:2617
      Check the value returned by _glamor_create_tex() in glamor_create_fbo()
      and return NULL in the texture is zero.
      All callers of glamor_create_fbo() actually check the returned value and
      will use a fallback code path if it's NULL.
      Please cherry-pick this to active stable branches.
      Bugzilla: https://bugzilla.redhat.com/1433305
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
    • Adam Jackson's avatar
      fb: Remove 24bpp support (v3) · 0803918e
      Adam Jackson authored
      - Require power-of-two bpp in ScreenInit
      - Eliminate fbCreatePixmapBpp
      - Squash in the exa and glamor changes so we can remove pRotatedPixmap
        in the same stroke.
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • 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
      v2: Fix command line options to silently ignore 24bpp rather than fail
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • 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: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  6. 16 Mar, 2017 2 commits
  7. 15 Mar, 2017 6 commits
  8. 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>
    • 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.
      Keep a cache of readlink results so it isn't quite so dreadfully slow.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  9. 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
      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>
  10. 09 Mar, 2017 3 commits
  11. 07 Mar, 2017 2 commits
  12. 06 Mar, 2017 1 commit
  13. 02 Mar, 2017 4 commits