[Xquartz-changes] xserver: Changes to 'server-1.16-branch'
Jeremy Huddleston
jeremyhu at freedesktop.org
Mon Aug 11 17:54:16 PDT 2014
New branch 'server-1.16-branch' available with the following commits:
commit af2e9e3bb173885106f041f89b9f39b57fe3550a
Author: Jeremy Huddleston Sequoia <jeremyhu at apple.com>
Date: Mon Aug 11 13:15:24 2014 -0700
XQuartz: Better support turning off "Displays have separate Spaces" on OS X Mavericks
http://xquartz.macosforge.org/trac/ticket/1876
Follow-up to: 1c10b37380d228b35db8a8616a6312ac54f5e59b
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu at apple.com>
(cherry picked from commit ab32ee35890be51137b56525826ffe219b63eb88)
commit b7a24467f738bfd9437e8de02ed5e44409054185
Author: Jeremy Huddleston Sequoia <jeremyhu at apple.com>
Date: Wed Jul 23 11:53:33 2014 -0700
ListenOnOpenFD: Remove Resets since this is intended to be for hotplugging connections
pharris says that the resets should not be done in the hotplugging case.
This may fix a crash reported against XQuartz:
http://xquartz.macosforge.org/trac/ticket/869
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu at apple.com>
Reviewed-by: Peter Harris <pharris at opentext.com>
(cherry picked from commit dfbc6a1a78ff3192baae6f7f2af98b6e51422f75)
commit a793483e38bfb8af19877f69e873c1776de18d1f
Author: Jeremy Huddleston Sequoia <jeremyhu at apple.com>
Date: Sat Jul 19 17:08:09 2014 -0700
mieq: Fix a crash regression in mieqProcessDeviceEvent
(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: 9fb08310b51b46736f3ca8dbc04efdf502420403
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu at apple.com>
Reviewed-by: Peter Hutterer <peter.hutterer at who-t.net>
(cherry picked from commit 1faa76670572e3478965fd2cd9ab60ab2d865e3a)
commit 3c0431b8911241552a15a43e4279c50658b50a18
Author: Keith Packard <keithp at keithp.com>
Date: Wed Jul 16 16:03:23 2014 -0700
glamor: Fix temp picture coordinates in glamor_composite_clipped_region
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: Keith Packard <keithp at keithp.com>
Reviewed-by: Markus Wick <markus at selfnet.de>
(cherry picked from commit 55f5bfb578e934319d1308cbb56c900c5ac7cfa7)
Signed-off-by: Julien Cristau <jcristau at debian.org>
More information about the Xquartz-changes
mailing list