__USLC__ appears to mean the SCO OpenServer compiler, which configure.ac
doesn't think is an OS the xfree86 ddx supports. The conditionals
surrounding these pragmas effectively mean "if not gcc and not Sun C",
and probably arbitrary pragmas aren't supported by arbitrary compilers.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
MetaWare High C++ compiler? xfree86 cvs history shows this being added
in a commit whose text is, classically, "updates". metaware.com
redirects to a 404 on synopsys.com, which to me indicates it's not super
important to them, and their order form won't even tell you how much the
thing costs. At any rate if this is worth worrying about it's worth
letting autoconf worry about for us.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
I guess this is meant to stub out all I/O port calls? Whatever, it's
not been defined by the buildsystem at least as far back as monolith
6.8.2.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Whatever these are, they're not something grep can find, they must not
be used.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is the only place they're actually used (well, aside from some XAA
code in the s3 driver, but one s3 and 2 XAA).
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Yes yes, very clever, memmove works fine on gcc too, let's just do the
portable thing since none of this is performance code.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Nothing in the server defines this, nor do any drivers.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Only used by mach64's XAA code, which isn't built if XAA isn't
available, and it isn't.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
I guess this might have been needed for elfloader, except we didn't
support nds32 back then, so I assume this was cargo-culted from
ppc_flush_icache, which is also dead now.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
xshmfence is usable outside of DRI3, and is currently autodetected which isn't
good for distributions where deterministic builds are desired.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Anytime a capability is first reported, the device is created, but after
that, it is only disabled/enabled.
This is a closer behavior to what Xorg does on VT switch, at the expense
of maybe leaving a dangling "physical" device if a capability goes for good.
Otherwise, any DeviceIntPtr (re)created after server initialization will be
left floating, and bad things happen when the wayland enter event handler
tries to update cursor position based on a floating device.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
These came in with the GATOS merge I think. The only driver using them
was radeon, and then only in UMS mode. The radeon driver dropped UMS
support from the main branch about two years ago, the UMS branch hasn't
been touched in about fifteen months, and does not build against 1.16 in
any case, so this is all dead code.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
At this point we have no architectures where image byte order is
different from bitmap bit order, or where either of those two are not
also the native word endianness. Hooray, one more place where we don't
have to worry about enabling new CPU architectures.
v2: Rebase to master to handle the addition of ppc64le, arc, and xtensa,
and use autoconf's endianness detection instead of gcc predefines.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
I really don't think this was ever correct, but I'm also not sure what
non-Linux Unix this was meant to enable. The only one I know of was
OS/390 / z/OS / OpenEdition, but I think that was big-endian too.
At any rate this is all about to go away, so this is just removing an
edge case.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This appears to be defining sparc if ever __sparc or __sparc__ were
defined, which is almost reasonable, but these days we want to be using
the __arch__ style. Why any of this would ever be triggered on m68k is
truly a mystery for the ages.
v2: Fix commit message, as noted by nix
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This effectively no longer varied across architectures anyway.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
These macros meant something in cfb, but not in fb.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Every other architecture sets this to 32, and I can't think of any
benefit s390 would derive from changing it. It is, at any rate,
something the client already copes with, and the only internal code
impact seems to be some complicated math in miGetPlane, which you never
hit if you're using fb.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Whatever unix this was meant to be is either no longer in circulation,
or is AIX, which we don't claim to support anyway.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
I forgot that the old behavior of searching in /usr/share/X11/xorg.conf.d was
documented in the man page.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Fixes: acc0b5edd1 ("xfree86: Only support one sysconfigdir")
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
I intended to use glFlush all along, but somehow managed to type
glFinish instead. glFlush is sufficient (for a single-queue GPU) to
ensure serialization between queued rendering in the X server and
future rendering from the client.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
This hooks up SHM sync fences to complete the requirements for DRI3
running on Glamor.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Compilation of -video-intel started failing in gnome-continuous,
it's because xserver has -Werror=return-type on, and gcc can't
prove this function always returns a value:
/usr/include/xorg/xf86platformBus.h:119:1: error: control reaches end of non-void function [-Werror=return-type]
Let's add assertions to the accessor functions to fix this.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
It's unused since keithp's copy acceleration code completely replaced
glamor_copyarea.c and removed the blit path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Unused since the glamor_prepare.c replacement of glamor_finish_access().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
All users of glamor had the same value set, and it complicated things
for no reason.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
After keithp's change to drop the old glamor_fill() code, nothing ever
changed these values.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
We're not drawing, and we're not initially setting up the texture for
later drawing.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
If this path needed the filters set, so would all the other
glDrawArrays() callers. But they don't.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This allows drivers to compile using the old OdevAttributes API
against a new server. It generates compiler errors if the caller uses
the wrong or undefined attribute types, or if the caller provides an
incorrect default value for an integer attribute.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
OdevAttributes are a fixed set of values with known types; instead of
storing them in a linked list and requiring accessor/settor functions,
replace the list header, struct OdevAttributes, with a struct that
directly contains the values. This provides for compile-time
typechecking of the values, eliminates a significant amount of code
and generally simplifies using this datatype.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
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>
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>
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>
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>
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>
