Skip to content
Snippets Groups Projects
  1. Nov 02, 2014
  2. Nov 01, 2014
  3. Oct 31, 2014
  4. Oct 29, 2014
  5. Oct 28, 2014
  6. Oct 10, 2014
    • Takashi Iwai's avatar
      fb: Fix invalid bpp for 24bit depth window · f7ca20ca
      Takashi Iwai authored and Julien Cristau's avatar Julien Cristau committed
      
      We have a hack in fb layer for a 24bpp screen to use 32bpp images, and
      fbCreateWindow() replaces its drawable.bitsPerPixel field
      appropriately.  But, the problem is that it always replaces when 32bpp
      is passed.  If the depth is 32, this results in bpp < depth, which is
      actually invalid.
      
      Meanwhile, fbCreatePixmap() has a more check and it creates with 24bpp
      only when the passed depth <= 24 for avoiding such a problem.
      
      This oneliner patch just adds the similar check in fbCreateWindow().
      This (hopefully) fixes the long-standing broken graphics mess of
      cirrus KMS with 24bpp.
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
      (cherry picked from commit fe5018e0)
      Signed-off-by: default avatarJulien Cristau <jcristau@debian.org>
      f7ca20ca
  7. Sep 21, 2014
  8. Sep 15, 2014
  9. Sep 10, 2014
  10. Aug 11, 2014
  11. Jul 28, 2014
    • Jeremy Huddleston Sequoia's avatar
      mieq: Fix a crash regression in mieqProcessDeviceEvent · a793483e
      Jeremy Huddleston Sequoia authored
      
      (lldb) bt
      * thread #6: tid = 0x92d4eb, 0x00000001001dee94 X11.bin`mieqProcessDeviceEvent(dev=0x0000000000000000, event=0x0000000100298bb0,
      screen=0x0000000000000000) + 36 at mieq.c:519, stop reason = EXC_BAD_ACCESS (code=1, address=0x44)
        * frame #0: 0x00000001001dee94 X11.bin`mieqProcessDeviceEvent(dev=0x0000000000000000, event=0x0000000100298bb0, screen=0x0000000000000000) + 36 at
      mieq.c:519
          frame #1: 0x00000001001df3eb X11.bin`mieqProcessInputEvents + 555 at mieq.c:631
          frame #2: 0x0000000100017674 X11.bin`ProcessInputEvents + 20 at darwinEvents.c:422
          frame #3: 0x0000000100175eaa X11.bin`Dispatch + 154 at dispatch.c:357
          frame #4: 0x0000000100181b4a X11.bin`dix_main(argc=4, argv=0x00007fff5fbff750, envp=0x00007fff5fbff650) + 1594 at main.c:296
          frame #5: 0x000000010001ba80 X11.bin`server_thread(arg=0x0000000101208220) + 64 at quartzStartup.c:66
          frame #6: 0x00007fff89bb9899 libsystem_pthread.dylib`_pthread_body + 138
          frame #7: 0x00007fff89bb972a libsystem_pthread.dylib`_pthread_start + 137
          frame #8: 0x00007fff89bbdfc9 libsystem_pthread.dylib`thread_start + 13
      
      Regression from: 9fb08310
      
      Signed-off-by: default avatarJeremy Huddleston Sequoia <jeremyhu@apple.com>
      Reviewed-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit 1faa7667)
      a793483e
  12. Jul 18, 2014
    • Keith Packard's avatar
      glamor: Fix temp picture coordinates in glamor_composite_clipped_region · 3c0431b8
      Keith Packard authored and Julien Cristau's avatar Julien Cristau committed
      
      To understand this patch, let's start at the protocol interface where
      the relationship between the coordinate spaces is documented:
      
              static Bool
              _glamor_composite(CARD8 op,
                                PicturePtr source,
                                PicturePtr mask,
                                PicturePtr dest,
                                INT16 x_source,
                                INT16 y_source,
                                INT16 x_mask,
                                INT16 y_mask,
                                INT16 x_dest, INT16 y_dest,
                                CARD16 width, CARD16 height, Bool fallback)
      
      The coordinates are passed to this function directly off the wire and
      are all relative to their respective drawables. For Windows, this means
      that they are relative to the upper left corner of the window, in
      whatever pixmap that window is getting drawn to.
      
      _glamor_composite calls miComputeCompositeRegion to construct a clipped
      region to actually render to. In reality, miComputeCompositeRegion clips
      only to the destination these days; source clip region based clipping
      would have to respect the transform, which isn't really possible. The
      returned region is relative to the screen in which dest lives; offset by
      dest->drawable.x and dest->drawable.y.
      
      What is important to realize here is that, because of clipping, the
      composite region may not have the same position within the destination
      drawable as x_dest, y_dest. The protocol coordinates now exist solely to
      'pin' the three objects together.
      
              extents->x1,y1		Screen origin of clipped operation
              width,height            Extents of the clipped operation
              x_dest,y_dest		Unclipped destination-relative operation coordinate
              x_source,y_source	Unclipped source-relative operation coordinate
              x_mask,y_mask		Unclipped mask-relative operation coordinate
      
      One thing we want to know is what the offset is from the original
      operation origin to the clipped origin
      
              Destination drawable relative coordinates of the clipped operation:
      
                     x_dest_clipped = extents->x1 - dest->drawable.x
                     y_dest_clipped = extents->y1 - dest->drawable.y
      
              Offset from the original operation origin:
      
                      x_off_clipped = x_dest_clipped - x_dest
                      y_off_clipped = y_dest_clipped - y_dest
      
              Source drawable relative coordinates of the clipped operation:
      
                      x_source_clipped = x_source + x_off_clipped;
                      y_source_clipped = y_source + y_off_clipped;
      
              Mask drawable relative coordinates of the clipped operation:
      
                      x_mask_clipped = x_source + x_off_clipped;
                      y_mask_clipped = y_source + y_off_clipped;
      
      This is where the original code fails -- it doesn't subtract the
      destination drawable location when computing the distance that the
      operation has been moved by clipping. Here's what it does when
      constructing a temporary source picture:
      
              temp_src =
                  glamor_convert_gradient_picture(screen, source,
                                                  extent->x1 + x_source - x_dest,
                                                  extent->y1 + y_source - y_dest,
                                                  width, height);
              ...
              x_temp_src = -extent->x1 + x_dest;
              y_temp_src = -extent->y1 + y_dest;
      
      glamor_convert_gradient_picture needs source drawable relative
      coordinates, but that is not what it's getting; it's getting
      screen-relative coordinates for the destination, adjusted by the
      distance between the provided source and destination operation
      coordinates. We want x_source_clipped and y_source_clipped:
      
              x_source_clipped = x_source + x_off_clipped
                               = x_source + x_dest_clipped - x_dest
                               = x_source + extents->x1 - dest->drawable.x - x_dest
      
      x_temp_src/y_temp_src are supposed to be the coordinates of the original
      operation translated to the temporary picture:
      
              x_temp_src = x_source - x_source_clipped;
              y_temp_src = y_source - y_source_clipped;
      
      Note that x_source_clipped/y_source_clipped will never be less than
      x_source/y_source because all we're doing is clipping. This means that
      x_temp_src/y_temp_src will always be non-positive; the original source
      coordinate can never be strictly *inside* the temporary image or we
      could have made the temporary image smaller.
      
              x_temp_src = x_source - x_source_clipped
                         = x_source - (x_source + x_off_clipped)
                         = -x_off_clipped
                         = x_dest - x_dest_clipped
                         = x_dest - (extents->x1 - dest->drawable.x)
      
      Again, this is off by the destination origin within the screen
      coordinate space.
      
      The code should look like:
      
              temp_src =
                  glamor_convert_gradient_picture(screen, source,
                                                  extent->x1 + x_source - x_dest - dest->pDrawable->x,
                                                  extent->y1 + y_source - y_dest - dest->pDrawable->y,
                                                  width, height);
      
              x_temp_src = -extent->x1 + x_dest + dest->pDrawable->x;
              y_temp_src = -extent->y1 + y_dest + dest->pDrawable->y;
      
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: default avatarMarkus Wick <markus@selfnet.de>
      (cherry picked from commit 55f5bfb5)
      Signed-off-by: default avatarJulien Cristau <jcristau@debian.org>
      3c0431b8
  13. Jul 17, 2014
  14. Jul 14, 2014
  15. Jul 13, 2014
  16. Jul 10, 2014
  17. Jul 07, 2014
  18. Jul 03, 2014
  19. Jun 25, 2014
  20. Jun 24, 2014
  21. Jun 23, 2014
Loading