On FreeBSD 13.0-CURRENT for PowerPC64 big-endian (BE), X was
crashing in some cases. For instance, when twm was started
and the background was clicked to open its menu, X crashed
with a segmentation fault, trying to dereference a null pointer
at CreatePicture().
There were 2 issues with xorg-server handling of RGB masks that
caused the pointer above to be null and thus the crash:
- wrong use of ffs() to get the RGB offsets from the masks
- overflow when shifting a 16-bit integer
This change fixes both issues. They happen when the system is BE
but has a video adapter using a little-endian (LE) ARGB32
framebuffer. In order to display the correct colors, this setup
requires a BE RGBA32 color format to be used by X, by setting
the RGB masks appropriately, that didn't work properly because of
the issues above.
This ensures that any prep work for the drawable we're about to read
from is already done before we call down to GetImage. This should be no
functional change as most of the callers with a non-trivial
SourceValidate are already wrapping GetImage and doing the equivalent
thing, but we'll be simplifying that shortly.
More importantly this ensures that if any of that prep work would
generate events - like automatic compositing flushing rendering to a
parent pixmap which then triggers damage - then it happens entirely
before we start writing the GetImage reply header.
Note that we do not do the same for GetSpans, but that's okay. The only
way to get to GetSpans is through miCopyArea or miCopyPlane - where the
callers must already call SourceValidate - or miGetImage - which this
commit now protects with SourceValidate.
Fixes: xorg/xserver#902
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Slightly simplifies the callers since they don't need to check for
non-NULL anymore.
I do extremely hate the workarounds here to suppress misprite taking the
cursor down though. Surely there's a better way.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Delightfully this is undefined even though CARD16 is an "unsigned" type,
because it's an unsigned short, which C promotes to signed int because
everything is stupid.
The Render protocol requires this format, but it is wrong to do so. We
are not aware of any hardware with a real 4bpp implementation of this
format. Some GL hardware may have GL_LUMINANCE4_ALPHA4_EXT, and may also
be able to wire L to 1, but that would win you none of memory, quality,
or (likely) performance over A8. Any attempt to use this format is
therefore likely a (painful) software fallback.
Pleasantly (and given the above, unsurprisingly) it seems to be unused
in the wild. None of the major toolkits will try to use it, and
rendercheck does not in fact validate that all of the "standard" picture
formats exist.
Drop the explicit A4 setup from picture format initialization. Note that
the DDXes are not changed and still expose a depth-4 pixmap format, but
we only add picture formats for True/DirectColor-credible depths (i.e.
depth >= 15).
Implements: xorg/proto/xorgproto!1
Signed-off-by: Adam Jackson <ajax@redhat.com>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This plumbs the full width color for solid pictures through to fb, exa,
and glamor. External drivers and acceleration code may wish to make a
similar change for sufficiently new servers.
v2: Don't break ABI (Michel Dänzer)
v2.1: Use the (correct) full color in fb too (Michel Dänzer)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Make a solid-fill picture for this instead of a 1x1 pixmap. In principle
the backend can accelerate this directly, and we also get to preserve
all the bits of the fill color.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Formerly spriteInfo->anim.pCursor would point to the animated cursor (or
NULL if not animated). That value would also be available in
spriteInfo->sprite->current, so instead lets use anim.pCursor to point
to the current animation element.
Signed-off-by: Adam Jackson <ajax@redhat.com>
We weren't cancelling the old timer when changing cursors, making things
go all crashy. Logically we could always cancel the timer first, but
then we'd have to call TimerSet to re-arm ourselves, and GetTimeInMillis
is potentially expensive.
Reported-by: https://devtalk.nvidia.com/default/topic/1028172/linux/titan-v-ubuntu-16-04lts-and-387-34-driver-crashes-badly/post/5230967/#5230967
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
This is very slightly more efficient since the callback now doesn't need
to walk every input device, instead we know exactly which device's
cursor is being updated. AnimCurTimerNotify() gets outdented nicely as a
result. A more important side effect is that we can stop using the
TimerAbsolute mode and just pass in the relative delay.
In AnimCurSetCursorPosition, we no longer need to rearm the timer with
the new screen; it is enough to update the device's state. In
AnimCurDisplayCursor we need to notice when we're switching from
animated cursor to regular and cancel the existing timer.
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Tested-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If the return value is non-zero here, DoTimer() will automatically rearm
the timer for the new (relative) delay. 'soonest' is in absolute time,
so subtract off 'now' and return that.
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Tested-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with
the ARRAY_SIZE macro from dix.h when possible. A semantic patch for
coccinelle has been used first. Additionally, a few macros have been
inlined as they had only one or two users.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
ProcRenderCreateRadialGradient and ProcRenderCreateConicalGradient must
be protected against an integer overflow during length check. This is
already included in ProcRenderCreateLinearGradient since the fix for
CVE-2008-2362.
This can only be successfully exploited on a 32 bit system for an
out of boundary read later on. Validated by using ASAN.
Reviewed-by: Adam Jackson <ajax@redhat.com>
This touches everything that ends up in the Xorg binary; the big missing
part is GLX since that's all generated code. Cuts about 14k from the
binary on amd64.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes freedesktop.org bug https://bugs.freedesktop.org/show_bug.cgi?id=67484
If t->bottom is close to MIN_INT, removing top can wraparound, so do the check properly.
A similar fix should also be applied to pixman.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Probably pointless, if this fails you're not likely to get far...
Reviewed-by: Rémi Cardona <remi@gentoo.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This replaces the block/wakeup handlers with an OsTimer. This also
avoids problems with performing rendering during the wakeup handler.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
All the callers were already checking for failure, except that
createSourcePicture() itself was failing to check whether it
successfully allocated the Picture.
[ajax: Rebase, fix line wrap of preceding line]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
==11097== 2,048 (+1,640) bytes in 32 (+26) blocks are definitely lost in loss record 1,570 of 1,719
==11097== at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11097== by 0x225EF3: SetPicturePictFilter (filter.c:339)
==11097== by 0x22DF4F: ProcRenderSetPictureFilter (render.c:1773)
==11097== by 0x15D25D: Dispatch (dispatch.c:432)
==11097== by 0x14C7B9: main (main.c:298)
[ajax: Fixed whitespace]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since ProcRenderScale throws BadImplementation anyway it's pointless to
waste time carefully swapping the request.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Otherwise we may be reading outside of the client request.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
ChangePicture takes wire XIDs, but didn't do any Xinerama translation,
which meant setting a clip pixmap or a separate alpha picture would
result in those elements pointing at the instance of the pixmap on
screen 0. Which is, you know, bad.
v2: This one actually builds.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49170
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This does have one semantic change. FixesCreateRegionFromPicture used to
throw BadImplementation if you tried to create a region from a picture
with no client clip. I changed that to BadMatch here since that more
honestly describes what's going on.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Arguably this would be useful API, but it's never called, and a careful
reading of the CPClipMask path reveals that callers would be fairly
disappointed.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Just throw BadPicture instead of crashing. It's not currently a
meaningful thing to do anyway, RenderSetPictureRectangles would error if
you tried (which this patch changes to BadPicture as well for
consistency). The problem with trying to do it is if the clip is
specified as a pixmap then we try to convert it to a region, and
->BitmapToRegion requires a ScreenPtr, and source-only pictures don't
have one.
I can imagine a use for client clip on source-only pictures, so if we
really wanted to allow this, probably the way forward is to always store
the clip as a region internally, and when setting the clip _from_ a
pixmap, look up BitmapToRegion relative to the pixmap not the picture.
But since clearly nobody can be relying on it working...
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Too many callers relied on the refcnt being handled correctly. Use a simple
wrapper to handle that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The loop above the previous call may end up triggering other
handlers attaching to the same function slot, so unwrapping
the handler after that could leave the just attached handler
in a dangling but not unset state.
This issue was most visible on the XO, where destroying a
window with an animated cursor set and running would trigger
this inconsistent state, never calling the miSpriteBlockHandler
again after the animated cursor is unset.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hotplugging screens causes the render filter names to get freed while
still in use; wait for the last core screen to be closed before
freeing them. That only happens at server reset, when we want them to
be freed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
No-one has used this since 0a71e154.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Create extinit.h (and xf86Extensions.h, for Xorg-specific extensions) to
hold all our extension initialisation prototypes, rather than
duplicating them everywhere.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Daniel Stone <daniel@fooishbar.org>
Ensures padding bytes are zero-filled
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Daniel Stone <daniel@fooishbar.org>
luporl
Jan Beich
Adam Jackson
Thierry Reding
Daniel Martin
Nathan Kidd
Eric Anholt
Tobias Stoeckmann
Maarten Lankhorst
Julien Cristau
Keith Packard
Chris Wilson
Andrea Canciani
Alan Coopersmith
Peter Hutterer
Carlos Garnacho
Yaakov Selkowitz
Daniel Stone