Update to version 1.16.0

Signed-off-by: Keith Packard <keithp@keithp.com>
Avoid starting a comment with */*

Even though -Wcomment doesn't mind it (in gcc or clang), the appearance
of */* confuses the syntax highlighter of some editors (eg. vim), and
causes warnings in MSVC.

Signed-off-by: Peter Harris <pharris@opentext.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Document how to correctly wrap screen procedures

This adds a large comment to include/scrnintstr.h which should serve
to document the correct way to wrap any screen procedure, with a
particular focus on how to dynamically add/remove wrapping layers
while the server is running.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
hw/xfree86: Fix block handler wrapping in xf86Rotate

xf86Rotate, it was delaying unwrapping the BlockHandler until after
calling xf86RotateRedisplay. If there was a software cursor on the
screen, the redisplay operation would cause cursor to be removed from
the frame buffer and the misprite block handler to be inserted into
the block handler chain with the misprite screen private saved block
handler now set to xf86RotateBlockHandler.

When xf86RotateRedisplay returned, xf86RotateBlockHandler would then
set screen->BlockHandler to its saved value, call down and then reset
screen->BlockHandler to xf86RotateBlockHandler. miSpriteBlockHandler
would never be called after that, which meant that the software cursor
will now disappear from the screen whenever rendering overlapped and
would only reappear when the cursor was moved.

To correct this, all that is needed is to move the restoration of
screen->BlockHandler to the top of xf86RotateBlockHandler, before the
call to xf86RotateRedisplay.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
mi: Fix block handler wrapping in miSprite

miSpriteBlockHandler was leaving the BlockHandler wrapped until just
before calling any nested block handler. If any code executed before
that added or removed block handlers, the wrapping chain would have
been broken.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
hw/xfree86: Fix VGA arbiter screen proc wrapping

Change the screen proc epilog code to re-fetch the current screen
function in case a nested proc changes how things work. This isn't a
problem with the current code as all of the wrapping layers that are
set up at server init time (like the VGA arbiter) leave themselves in
the screen proc chain forever. But, this makes the code conform with
the expected norms.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
hw/xfree86: Let xf86Rotate leave the BlockHandler unwrapped when possible

When no shadow frame buffer is needed, the rotate block handler
doesn't need to be called any more. Remove it from the chain.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
ephyr: Free damage structure at server reset time

The usual mechanism for freeing a damage structure when the pixmap is
destroyed does not work for the screen pixmap as it isn't freed in the
normal way.

The existing driver cleanup function, scrfini, is called after the
wrapped CloseScreen functions, including damageCloseScreen, are called
and thus ephyr can't free the damage structure at that point.

Deal with this by providing an early CloseScreen hook in KdCloseScreen
which ephyr can use to free the damage structure before damage itself
shuts down.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Post 1.16 version bump to 1.16.99.1

And we're off towards 1.17; this version bump serves to keep
development versions distinct from stable versions.

Signed-off-by: Keith Packard <keithp@keithp.com>
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@keithp.com>
Reviewed-by: Markus Wick <markus@selfnet.de>