1. 27 Mar, 2017 1 commit
  2. 24 Mar, 2017 1 commit
  3. 23 Mar, 2017 8 commits
  4. 21 Mar, 2017 2 commits
  5. 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>
      40c12a76
    • 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: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      1ad23068
    • 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: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      4aa35c46
    • 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: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      368f60d4
  6. 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/1433305Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      8805a48e
    • Adam Jackson's avatar
      fb: Remove 24bpp support (v3) · 0803918e
      Adam Jackson authored
      v2:
      - Require power-of-two bpp in ScreenInit
      - Eliminate fbCreatePixmapBpp
      
      v3
      - Squash in the exa and glamor changes so we can remove pRotatedPixmap
        in the same stroke.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      0803918e
    • 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
  7. 16 Mar, 2017 2 commits
  8. 15 Mar, 2017 6 commits
  9. 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
  10. 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
  11. 09 Mar, 2017 3 commits
  12. 07 Mar, 2017 2 commits
  13. 06 Mar, 2017 1 commit
  14. 02 Mar, 2017 3 commits
    • Adam Jackson's avatar
      os: Squash missing declaration warning for timingsafe_memcmp · 5c44169c
      Adam Jackson authored
      timingsafe_memcmp.c:21:1: warning: no previous prototype for ‘timingsafe_memcmp’ [-Wmissing-prototypes]
       timingsafe_memcmp(const void *b1, const void *b2, size_t len)
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      5c44169c
    • Adam Jackson's avatar
      miarc: "Cache" arc span data for dashed arcs · 0d7f05ed
      Adam Jackson authored
      This avoids recomputing the span data for every dash. x11perf thinks
      this is a pretty modest speedup:
      
          832919.4       840471.1 ( 1.009)   100-pixel dashed ellipse
          672353.1       680652.2 ( 1.012)   100-pixel double-dashed ellipse
           13748.9        24287.9 ( 1.767)   100-pixel wide dashed ellipse
            9236.3        21298.2 ( 2.306)   100-pixel wide double-dashed ellipse
      
      But part of the reason it's so modest there is that the arcs are
      relatively small (100 pixel diameter at line width 10, so ~6000 pixels)
      and the dashes relatively large (30 on 20 off so ~6 dashes per
      quadrant).
      
      With larger arcs and finer dashes this is much more impressive. A fairly
      trivial testcase of a single 15000x13000 arc with the default {2, 2}
      dash pattern drops from ~3500 milliseconds to 10 milliseconds.
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      0d7f05ed
    • Adam Jackson's avatar
      miarc: Make the caller free the arc span data · 849c8258
      Adam Jackson authored
      drawArc does some fairly expensive computation, but it's only sensitive
      to arc width/height. Thread the span data up through the call chain so
      it's at least possible for the caller to cache things.
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      849c8258