1. 17 Nov, 2019 1 commit
  2. 15 Nov, 2019 1 commit
  3. 02 Nov, 2019 1 commit
  4. 07 Oct, 2019 1 commit
  5. 27 Sep, 2019 1 commit
  6. 19 Sep, 2019 21 commits
  7. 24 Jul, 2019 3 commits
  8. 19 Jul, 2019 1 commit
  9. 10 Jul, 2019 3 commits
  10. 01 Mar, 2019 2 commits
  11. 21 Feb, 2019 1 commit
    • Adam Jackson's avatar
      Fix build on i686 · 9e6e003e
      Adam Jackson authored
      Presumably this only matters for i686 because amd64 implies sse2, but:
      
      BUILDSTDERR: In file included from gen4_vertex.c:34:
      BUILDSTDERR: gen4_vertex.c: In function 'emit_vertex':
      BUILDSTDERR: sna_render_inline.h:40:26: error: inlining failed in call to always_inline 'vertex_emit_2s': target specific option mismatch
      BUILDSTDERR:  static force_inline void vertex_emit_2s(struct sna *sna, int16_t x, int16_t y)
      BUILDSTDERR:                           ^~~~~~~~~~~~~~
      BUILDSTDERR: gen4_vertex.c:308:25: note: called from here
      BUILDSTDERR:  #define OUT_VERTEX(x,y) vertex_emit_2s(sna, x,y) /* XXX assert(!too_large(x, y)); */
      BUILDSTDERR:                          ^~~~~~~~~~~~~~~~~~~~~~~~
      BUILDSTDERR: gen4_vertex.c:360:2: note: in expansion of macro 'OUT_VERTEX'
      BUILDSTDERR:   OUT_VERTEX(dstX, dstY);
      BUILDSTDERR:   ^~~~~~~~~~
      
      The bug here appears to be that emit_vertex() is declared 'sse2' but
      vertex_emit_2s is merely always_inline. gcc8 decides that since you said
      always_inline you need to have explicitly cloned it for every
      permutation of targets. Merely saying inline seems to do the job of
      cloning vertex_emit_2s as much as necessary.
      
      So to reiterate: if you say always-inline, it won't, but if you just say
      maybe inline, it will. Thanks gcc, that's helpful.
      9e6e003e
  12. 20 Feb, 2019 1 commit
  13. 21 Jan, 2019 1 commit
    • Mario Kleiner's avatar
      sna/uxa: Fix colormap handling at screen depth 30. (v2) · 33ee0c3b
      Mario Kleiner authored
      
      
      The various clut handling functions like a setup
      consistent with the x-screen color depth. Otherwise
      we observe improper sampling in the gamma tables
      at depth 30.
      
      Therefore replace hard-coded bitsPerRGB = 8 by actual
      bits per channel scrn->rgbBits. Also use this for call
      to xf86HandleColormaps().
      
      Tested for uxa and sna at depths 8, 16, 24 and 30 on
      IvyBridge, and tested at depth 24 and 30 that xgamma
      and gamma table animations work, and with measurement
      equipment to make sure identity gamma ramps actually
      are identity mappings at the output.
      
      v2: Also deal with X-Server 1.19 and earlier, which as of
          v1.19.6 lack a fix to color palette handling and can
          not deal with depths/bpc > 24/8 bpc. On < 1.20 we skip
          xf86HandleColormaps() setup at > 8 bpc. This disables
          color palette handling on such servers at > 8 bpc, but
          still keeps RandR gamma table handling intact.
      
          Tested on 1.19.6 and 1.20.0 to do the right thing.
      Signed-off-by: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: Ville Syrjälä's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      33ee0c3b
  14. 10 Jan, 2019 2 commits