wakeup handlers are called even when select() returns EINTR,
and when they're called the passed fd set is undefined.
This commit fixes the dbus wakeup handler to avoid dispatching
into dbus spuriously.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ray Strode <rstrode@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Commit 2f1aedcaed added several bug checks. Some
of them are not correct.
Checks in Init(Ptr|String|Bell|Led|Integer)FeedbackClassDeviceStruct verify
that no feedback struct was set yet, but that is not required. If any feedback
structs are already present, the function will chain them behind the new one.
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit 7353ec7cb6 "xfree86: Switch int10
code to stdint types" uses designated initializers to setup the fields
of the X86EMU_pioFuncs.
This breaks compilation on ARM, since out{b,w,l}() are redefined using
the preprocessor and therefore cause the compiler to complain about
non-existent fields being assigned to.
It seems like the compiler.h header that contains these redefinitions
isn't actually needed in xf86x86emu.c, so the easiest "fix" is to not
include it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Fixes:
stub.c:66:1: error: conflicting types for 'xf86int10Addr'
In file included from stub.c:14:0:
xf86int10.h:72:53: note: previous declaration of 'xf86int10Addr' was here
Signed-off-by: Rob Clark <robdclark@gmail.com>
There should be no reason to need a real int10 implementation on arm,
and switching to stub is an easy way to fix:
xf86x86emu.c: In function 'xf86Int10ExecSetup':
xf86x86emu.c:56:9: error: unknown field 'xf_outb' specified in initializer
xf86x86emu.c:57:9: error: unknown field 'xf_outw' specified in initializer
xf86x86emu.c:58:9: error: unknown field 'xf_outl' specified in initializer
which is caused by the following in compiler.h:
#define outb xf_outb
#define outw xf_outw
#define outl xf_outl
Signed-off-by: Rob Clark <robdclark@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Create load_cursor_image_check, load_cursor_argb_check,
LoadCursorImageCheck and LoadCursorARGBCheck that can return failure
and use them in preference to the old unchecked variants.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Michael Thayer <michael.thayer@oracle.com>
The attack surface for indirect GLX is huge, and it's of no use to
most people (if you get an indirect GL context, you're better served
by a immediate X error than actually trying to use an indirect GL
context and finding out that it doesn't support doing anything you
want, slowly). This flag gives you a chance to disable indirect GLX
in environments where you just don't need it.
I put in both the '+' and '-' arguments right now, so that it's easy
to patch the value to change the default policy.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Even when create a pixmap which smaller than the max_fbo_size,
it may fail due to some low level driver limitation. If that is
the case, we don't need to crash the xserver. We just need to
fallback to system memory.
See the related bug at:
https://bugs.freedesktop.org/show_bug.cgi?id=71190
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Kai Wasserbach <kai@dev.carbon-project.org>
Tested-by: Erich Seifert <eseifert@error-reports.org>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
It would leak the memory allocated for the region rects in some cases.
Found with valgrind.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
There were actually two issues with the original code I believe, the
first is that the call to glamor_convert_gradient_picture wasn't
properly referencing the coordinates of the source/mask pictures. The
second, was that the updated references (x_temp/y_temp) were also
improperly set, they should always be 0 because the temp pictures are
new ones that start at (0, 0). The reason it worked in certain cases
and it didn't in others (notably the tray icons) was due to the
numbers working out based on the call to glamor_composite. In the
cases that it did work extent->x1 would equal x_dest and extent->y1
would equal y_dest, making it so what was actually passed into
glamor_convert_gradient_picture and the settings for x_temp/y_temp
were correct. However, for the case when extent->x1 wouldn't equal
x_dest and extent->y1 wouldn't equal y_dest (for example with the tray
icons) then the wrong parameters get passed into
glamor_convert_gradient_picture and x_temp/y_temp are set improperly.
Fixes issues with tray icons not appearing properly in certain cases.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=64738
Signed-Off-by: Anthony Waters <awaters1@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
These use the upload_boxes and download_boxes helpers to provide
reasonably efficient image transfer.
Fixes segfaults in Xephyr with x11perf -reps 1.
Performance improvements:
Improves -putimage10 by 548.218% +/- 88.601% (n=10).
Improves -putimage500 by 3.71014% +/- 1.5049% (n=10).
Improves -getimage10 by 8.37004% +/- 4.58274% (n=10).
No statistically significant difference on -getimage500 (n=10).
v2: Fix rebase failures, don't forget to check/prepare the gc in
putimage fallbacks (changes by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
When sourcing a picture that has no alpha values, make sure any
texture fetches wire the alpha value to one. This ensures that bits
beyond the depth of the pixmap, or bits other than the RGB values
aren't used.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
By changing the context, it may also invalidate the DRI2 buffer
information, so we need to get that again.
Fixes crashes due to use-after-free with LIBGL_ALWAYS_INDIRECT=1
glxgears and piglit.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Fixes a usage of the wrong context with swrast GLX's GetImage entrypoint.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Now that we have the DIX global state for the current context, we
don't need to track nesting to try to reduce MakeCurrent overhead.
v2: Fix a mistaken replacement of a put_context with make_current in
glamor_fill_spans_gl() (caught by keithp).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com> (v1)
This matches the Xephyr behavior. Now that we know when to reset the
context in the presence of GLX, we don't need to try to keep our stuff
from being smashed by GLX.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This gets us some more context changes that are needed to make sure
the two sides render to the right drawables and manipulate the right
objects.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
These functions are called from the GL driver, in some series of GL
calls by GLX. If some server component (like glamor CreatePixmap for
GetBuffers()) changes the GL context on us, we need to set it back or
the later GL calls will land in the glamor context instead of the GLX
context.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
I needed to add some code to each one, so it's a good time to make a
helper func.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This hook calls unbindContext in the DRI driver interface, which
unsets the dispatch table, regardless of whether the context argument
was the current one or not.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
We want to make sure that lastGLContext is set correctly during
makeCurrent, because we may have recursive GL context changes in the
DRI2 interfaces due to glamor.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
GLX is trying to track whether the context it wants is current, to
avoid the glFlush() (and the rest of the overhead) that occurs on all
MakeCurrent calls. However, its cache can be incorrect now that
glamor exists. This is a step toward getting glamor to coordinate
with GLX.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There is some complicated code to support tweaking the format as we
upload from a SHM pixmap (aka the GTK icon cache), but if we weren't
sourcing from a SHM pixmap we just forgot to check that the formats
matched at all.
We could potentially be a little more discerning here (xRGB source and
ARGB mask would be fine, for example), but this will all change with
texture views anyway, so just get the rendering working for 1.16
release.
Fixes the new rendercheck gtk_argb_xbgr test.
v2: Squash in keithp's fix for checking that we have a non-NULL
pixmap, and reword the comment even more.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Bad anholt, no biscuit. Broken in commit
4c9a200725.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
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>
When setting crtc->gamma_size to randr_crtc->gammaSize we should
use randr_crtc->gammaSize to allocate new gamma table in crtc.
Currently, if randr_crtc->gammaSize > crtc->gammaSize the subsequent
memcpy will overwrite memory beyond the end of gamma table.
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes a valgrind complaint:
==8805== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==8805== at 0x5EB8315: __libc_sigaction (sigaction.c:66)
==8805== by 0x5B13DA: busfault_init (busfault.c:145)
==8805== by 0x5A60A2: OsInit (osinit.c:191)
==8805== by 0x46EBA2: dix_main (main.c:163)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Mark mips64 as 64bit
Use long as PORT_SIZE
Signed-off-by: YunQiang Su <wzssyqa@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Just use floats, it's not like this is a performance path.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Ok, that's embarassing -- I didn't even make sure Adam's patch
compiled. These are minimal fixes to make it build.
Signed-off-by: Keith Packard <keithp@keithp.com>
Somewhat shocking how much simpler this is, isn't it? We no longer need
to wrap the screen or GC or Picture, because damage does it for us,
which is doubly great since the old shadowfb code didn't wrap _enough_
things (border updates and Render glyphs, at least). The only real
difference now between this and shadow is a) shadow will let you track
arbitrary pixmaps, and b) shadow's update hook runs off the BlockHandler
whereas shadowfb is immediate.
Tested on nouveau.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Flagged by cppcheck 1.64:
[hw/dmx/config/xdmxconfig.c:306] -> [hw/dmx/config/xdmxconfig.c:323]:
(warning) Possible null pointer dereference: fs - otherwise
it is redundant to check it against null.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
It wasn't possible to build glamor from tarballs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64297#c9
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
On systems without these directories, we don't need to be complaining
loudly.
Reviewed-by: Kristian Hoegsberg <krh@bitplanet.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Automake 1.12 introduces a new parallel test framework that uses a shell
script helper and generates *.log and *.trs files. Add to .gitignore.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Keith Packard <keithp@keithp.com>
The protocol handlers all have support for swapping variable data and
replies, but the top-level dispatch plumbing was missing.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Both xRRSetProviderOutputSourceReq and xRRSetProviderOffloadSinkReq are
fixed-size requests, so the length on the wire should match exactly.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The previous code was checking the wrong table for function pointers.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes Piglit test "swapbuffersmsc-return swap_interval 0".
Ensure that *swap_target gets initialized on any 'return Success' path,
even if the swap request can't be completed by the driver and the server
falls back to a simple blit. That path can also be triggered by setting
swap_interval to 0, which disables sync to vertical retrace.
We originally found this bug because for some reason SDL2 automatically
sets swap_interval to 0, when we were trying to test OML_sync_control in
an SDL2 test application. We then discovered that the above-mentioned
Piglit test has been failing for the same reason since it was
introduced.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Theo Hill <Theo0x48@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
