| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
- Avoid some needlessly complex equations for calculating the color at a
point in a gradient field.
- Avoid calculating certain values multiple times.
- Use similar variable names across the two versions of the get_color
function where practical.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit ff410c56bfd6dcdf5d252ef0ba3f4c6fde91774b)
|
|
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 3bd17dff1ac5a4685a5da92a9982f621effee658)
|
|
When compositing a no-reflect gradient, 'before' the gradient is empty,
but 'after' the gradient is padded with the final color. Both sides are
supposed to be empty.
This is fixed by moving the virtual stops to match the first and last
client-supplied stops for no-reflect gradients, then causing everything
'before' the initial virtual stop and 'after' the final virtual stop to
emit rgba(0,0,0,0). This does not impact gradients using the other
reflect modes.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 5815c7b5951fd46d69e5c40144b64e516c7afdbf)
|
|
If _pt_distance is negative, it causes the final distance to be negative
in the repeat-reflect case. Moving the scaling by _pt_distance earlier
avoids this problem, and simplifies some equations as a bonus.
Bugzilla: https://bugs.freedesktop.org/98508
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 3e377e238f7257fd01e56a4a25dfd77e033673e4)
|
|
SAMPLE is a GLSL keyword in newer OpenGL version.
This fix issue with gnome-shell and playing video using xv
Signed-off-by: Corentin Rossignon <corentin.rossignon@gmail.com>
Bugzilla: https://bugs.freedesktop.org/104405
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit dbfbe58b94ec07a45fd6170f96bffec55051724e)
|
|
glamor_compute_transform_clipped_regions() uses a temporary box32
internally which is copied back to a box16 to init the regions16,
thus causing a potential overflow.
If an overflow occurs, the given region is invalid and the pixmap
init region will fail.
Simply check that the coordinates won't overflow when copying back to
the box16, avoiding a crash later down the line in glamor.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=101894
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Fabrice Bellet <fabrice@bellet.info>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 9869dcb349b49f6d4cc2fab5d927cd8b1d1f463c)
|
|
COMPOSITE_REGION() can pass NULL as a source picture, make sure we
handle that nicely in both glamor_composite_clipped_region() and
glamor_composite_choose_shader().
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=101894
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit bd353e9b84e013fc34ed730319d5b63d20977903)
|
|
The previous values happened to work in basic cases, but not in general
if the destination is a subwindow or has a border.
Fixes crash with xli, which moves a large subwindow inside a smaller
parent window for scrolling.
No regressions with xterm, x11perf -copyplane or the xscreensaver
phosphor hack.
Bug: https://bugs.debian.org/857983
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit ffda82ed04d28feae2e001dbd0c32d6c795d90b1)
|
|
Fixes subtle breakage which could sometimes trigger after a server reset
with multiple screens using glamor:
Screen A enters glamor_close_screen last and calls various cleanup
functions, which at some point call glamor_make_current to make sure
screen A's GL context is current. This sets lastGLContext to screen A's
&glamor_priv->ctx. Finally, glamor_close_screen calls
glamor_release_screen_priv, which calls free(glamor_priv).
Later, screen B enters glamor_init, which allocates a new glamor_priv.
With bad luck, this can return the same pointer which was previously
used for screen A's glamor_priv. So when screen B's glamor_init calls
glamor_make_current, lastGLContext == &glamor_priv->ctx, so MakeCurrent
isn't called for screen B's GL context, and the following OpenGL API
calls triggered by glamor_init mess up screen A's GL context.
The observed end result of this was a crash in glamor_get_vbo_space
because glamor_priv->vbo didn't match the GL context, though there might
be other possible outcomes.
Assigning the actual GL context pointer to lastGLContext prevents this
by preventing the false negative test in glamor_make_current.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 7c88977d338a01aca866e52c9e736f8857fb9ae4)
|
|
It appears that on some hardware/diver combo such as nv30/nouveau, using
GL_ALPHA as format for 8-bit depth will cause an incomplete attachment
error (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT) when trying to bind the
texture.
As a result, the FBO is NULL and glamor segfaults when trying to access
the FBO width/height in pixmap_priv_get_scale() in glamor_xv_render().
This happens with glamor-xv which uses 8-bit pixmaps, meaning that on
such hardware/driver, trying to play a video using Xv will lead to a
crash of the Xserver. This affects Xwayland, Xephyr, modesetting driver
with glamor accel.
But the use of an FBO is not actually needed for glamox-xv, so by
disabling FBO at pixmap creation, we can avoid the issue entirely.
Fix suggested by Eric Anholt <eric@anholt.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100710
Fixes: https://bugzilla.redhat.com/1412814
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 7bfb87a2137853295ecc9e544a15626cfd773a02)
|
|
Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY
is raised, in which case the texture returned is zero.
But the texture value is not checked in glamor_create_fbo() and glamor
will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0:
Truncated backtrace:
Thread no. 1 (10 frames)
#4 glamor_pixmap_ensure_fb at glamor_fbo.c:57
#5 glamor_create_fbo_from_tex at glamor_fbo.c:112
#6 glamor_create_fbo at glamor_fbo.c:159
#7 glamor_create_fbo_array at glamor_fbo.c:210
#8 glamor_create_pixmap at glamor.c:226
#9 compNewPixmap at compalloc.c:536
#10 compAllocPixmap at compalloc.c:605
#11 compCheckRedirect at compwindow.c:167
#12 compRealizeWindow at compwindow.c:267
#13 RealizeTree at window.c:2617
Check the value returned by _glamor_create_tex() in glamor_create_fbo()
and return NULL in the texture is zero.
All callers of glamor_create_fbo() actually check the returned value and
will use a fallback code path if it's NULL.
Please cherry-pick this to active stable branches.
Bugzilla: https://bugzilla.redhat.com/1433305
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 8805a48ed35afb2ca66315656c1575ae5a01c639)
|
|
We were binding the screen pixmap as the dash and sampling its alpha,
which is usually just 1.0 (no dashing at all).
Please cherry-pick this to active stable branches.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit fe0b297420fc1de8a7fab28457d0864b3182e967)
|
|
Check the value returned by glamor_set_destination_drawable() and use
the fallback code path where possible.
Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 455051a0f1d2bc84f605c325f647bd64d414c47d)
|
|
The fbo_array of a given glamor pixmap can be NULL in some cases, as
glamor_create_fbo_array() can fail to allocate the FBO array.
If this is the case, glamor_pixmap_fbo_at() will return NULL even though
the box index is valid, and glamor_set_destination_drawable() simply
assumes glamor_pixmap_fbo_at() will return an FBO prior to pass the
value to glamor_set_destination_pixmap_fbo(), which will segfault.
We need a way for glamor_set_destination_drawable() to fail safely and
let the caller know about the failure.
Add a boolean return value to glamor_set_destination_drawable() for that
purpose.
Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 04b4bad7c048fd077fe839f10634c99ef1e488af)
|
|
glamor_create_pixmap() would return a NullPixmap if the given size is
larger than the maximum size of a pixmap.
But glamor_get_pixmap_texture() won't check if the given pixmap is
non-null, leading to a segfault if glamor_create_pixmap() failed.
This can be reproduced by passing Xephyr a very large screen width,
e.g.:
$ Xephyr -glamor -screen 32768x1024 :10
(EE)
(EE) Backtrace:
(EE) 0: Xephyr (OsSigHandler+0x29)
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
(EE) 2: Xephyr (glamor_get_pixmap_texture+0x30)
(EE) 3: Xephyr (ephyr_glamor_create_screen_resources+0xc6)
(EE) 4: Xephyr (ephyrCreateResources+0x98)
(EE) 5: Xephyr (dix_main+0x275)
(EE) 6: /lib64/libc.so.6 (__libc_start_main+0xf1)
(EE) 7: Xephyr (_start+0x2a)
(EE) 8: ? (?+0x2a) [0x2a]
(EE)
(EE) Segmentation fault at address 0x0
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
Aborted (core dumped)
Bugzilla: https://bugzilla.redhat.com/1431633
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit f40ff18c96e02ff18a367bf53feeb4bd8ee952a0)
|
|
Fixes a GLSL compilation error:
Failed to compile VS: 0:13(43): error: `pos' undeclared
0:13(14): error: operands to arithmetic operators must be numeric
0:13(13): error: operands to arithmetic operators must be numeric
[1.19: Squash in Michel's typo fix from 0c1574d9]
Tested-by: Stefan Dirsch <sndirsch@suse.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit d8161aeb50891ae10c5656487ce8f982deed5f9f)
(cherry picked from commit 0c1574d9882a91b2c1a046bf4ac5a9b138a37965)
|
|
When selecting "CA_TWO_PASS" in glamor_composite_clipped_region() when
the hardware does not support "GL_ARB_blend_func_extended", we call
glamor_composite_choose_shader() twice in a row, which in turn calls
glamor_pixmap_ensure_fbo().
On memory pixmaps, the first call will set the FBO and the second one
will fail an assertion in glamor_upload_picture_to_texture() because
the FBO is already set.
Bail out earlier when the mask pixmap is in memory and the hardware
capabilities would require to use two pass, so that the assertion is not
failed and the rendering is correct.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99346
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 86463981361064dd0352ec215abf1696ce7fc5ea)
|
|
If the libEGL we are using has eglGetPlatformDisplayEXT, yet it still
returns NULL, then this very likely means that it does not support the
type (e.g. EGL_PLATFORM_GBM_MESA) passed in, and then returning NULL is
the right thing to do.
This avoids falling back to an eglGetDisplay() implementation which does
not understands the passed in gbm handle, treats it as a pointer to
something else completely, followed by a crash sooner or later.
Specifically this fixes using the nvidia binary driver, with nvidia's
libEGL + the modesetting driver on a secondary GPU crashing inside
glamor_egl_init() sometimes.
[1.19: squash in typo fix from 29a4f3db - ajax]
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 05e19644250698aa126a60bc671e85425df784d1)
|
|
In glamor_init(), if the minimum requirements are not met, glamor may
fail after setting up its own CloseScreen() and DestroyPixmap()
routines, leading to a crash when either of the two routines is called
if glamor failed to complete its initialization, e.g:
(EE) Backtrace:
(EE) 0: Xwayland (OsSigHandler+0x29)
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
(EE) 2: Xwayland (glamor_sync_close+0x2a)
(EE) 3: Xwayland (glamor_close_screen+0x52)
(EE) 4: Xwayland (CursorCloseScreen+0x88)
(EE) 5: Xwayland (AnimCurCloseScreen+0xa4)
(EE) 6: Xwayland (present_close_screen+0x42)
(EE) 7: Xwayland (dix_main+0x4f9)
(EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf1)
(EE) 9: Xwayland (_start+0x2a)
Restore the previous CloseScreen() and DestroyPixmap() vfunc handlers in
case of failure when checking for the minimum requirements, so that if
any of the requirement is not met we don't leave the CloseScreen() and
DestroyPixmap() from glamor handlers in place.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1390018
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit f43207c1c4a8487600cf3ea116c10437417c861b)
|
|
The extension does not exist in the registry, thus needs to know they're
using EGL 1.5 in order to determine the eglGetPlatformDisplay function
pointer is valid.
Thus brings us into some lovely circular dependency.
Since mesa won't be able (in the foreseeable future) to export the KHR
flavour of extension (another way one could assume that EGL 1.5 is
available) just drop all the heuristics and use the
EGL_EXT_platform_base extension.
In practise (checked with the Mali driver) any EGL 1.5 driver will
advertise support for EGL_EXT_platform_base.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
eglGetDisplay forces the implementation to guess which kind of display
it's been handed. glvnd does something different from Mesa, and in
general it's impossible for the library to get this right. Add a new
inline that gets the logic right, and works around a quirk in epoxy.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Commit cba28d5 - "glamor: Handle bitplane in glamor_copy_fbo_cpu"
introduced a regression as the computed pixmap offset would not match
the actual coordinates and write data elsewhere in memory causing a
segfault in fbBltOne().
Translate the pixmap coordinates so that the data is read and written at
the correct location.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97974
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
In commit 9e9fcf5 (glamor: Add a helper function for the common
GL_QUADS fallback pattern.), the glDrawArrays count change was
accidentally changed to nbox.
Fixes xlogo with MESA_GL_VERSION_OVERRIDE=2.1 and
MESA_GLSL_VERSION_OVERRIDE=120
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Current Mesa requires that the precision qualifier on uniforms matches
between stages, even if (as in this case) the uniform isn't used in
one of the stages.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
I don't think anybody has run this code since it was pulled into the
server.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
The extension came out in 2000, and all Mesa-supported hardware that
can do glamor supports it. We were already relying on the ARB version
being present on desktop.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
glUniform4ui is available starting in GL{,ES} 3.0. Technically it's
also in EXT_gpu_shader4, but that's not worth supporting. There was also
a MESA_shading_language_130 spec proposed at one point; if that ever
gets finished, we can update epoxy to know about it and fix up the
feature check.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Even if the pixmap's storage has alpha, it may have been uploaded with
garbage in the alpha channel, so we need to force the shader to set
alpha to 1. This was broken way back in
355334fcd99e4dce62e2be1e27290c9a74ea944f.
Fixes rendercheck -t composite -f x8r8g8b8.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
replicated a bug from last time we did a copy optimization: CopyArea
is only defined for matching depths. This is only a problem at 15 vs
16 depth right now (24 vs 32 would also have matching Render formats,
but they should work) but be strict in case we store other depths
differently in the future.
Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4
v2: Drop excessive src->depth == dst->depth check that snuck in.
v3: Switch back to src->depth == dst->depth
v4: Touch up commit message (s/bpp/depth).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
This was clearly x-indent.sh damage.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
This function is used by the modesetting driver to implement DRI2 and
shouldn't fail on systems that don't support DRI3.
v2: Drop stale commit message wording, fix compiler warning (by anholt)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
v2: Fix "orignal" too (review feedback by ajax, change by anholt)_
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
When a GPU gets hotplugged while X is already running, glamor_egl_init()
gets called and changes the current egl context, without updating
lastGLContext, potentially causing the next glamor call on another GPU to
run in the wrong context.
This causes glamor to e.g. crash in the next glamor_create_pixmap() call
(called through the master's screen->CreatePixmap), note this is not the
only troublesome entry point I've seen other backtraces when using a
compositing window manager.
Set lastGLContext to NULL to force the next glamor_make_current() call
to set the right context.
Note that we cannot use glamor_make_current() here to replace the
eglMakeCurrent() call and update lastGLContext for us because
glamor_make_current takes a glamor_priv struct as argument and that
has not been created yet when glamor_egl_init() gets called.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Add glamor_shareable_fd_from_pixmap function to get dma-buf fds suitable
for sharing across GPUs (not using GPU specific tiling).
This is necessary for the modesetting driver to correctly implement
the DRI2 SharePixmapBacking callback.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Fixes shader compile failure:
Failed to compile VS: 0:13(43): error: `pos' undeclared
0:13(14): error: operands to arithmetic operators must be numeric
0:13(13): error: operands to arithmetic operators must be numeric
Program source:
#define ATLAS_DIM_INV 0.000976562500000000
attribute vec2 primitive;
attribute vec2 source;
varying vec2 glyph_pos;
uniform vec2 fill_offset;
uniform vec2 fill_size_inv;
varying vec2 fill_pos;
uniform vec4 v_matrix;
void main() {
gl_Position.xy = primitive.xy * v_matrix.xz + v_matrix.yw;
gl_Position.zw = vec2(0.0,1.0);
glyph_pos = source.xy * ATLAS_DIM_INV;
fill_pos = (fill_offset + primitive.xy + pos) * fill_size_inv;
}
(EE) Fatal server error:
(EE) GLSL compile failure
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97300
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
This can significantly speed up at least some CopyPlane cases, e.g.
indirectly for stippled fills.
v2:
* Make temporary pixmap the same size as the destination pixmap
(instead of the destination drawable size), and fix coordinate
parameters passed to fbCopyXtoX and glamor_upload_boxes. Fixes
incorrect rendering with x11perf -copyplane* and crashes with the
xscreensaver phosphor hack.
v3:
* Make the change a bit more compact and hopefully more readable by
re-using the existing src_* locals in the bitplane case as well.
Reported-by: Keith Raghubar <keith.raghubar@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Eric Anholt <eric@anholt.net>
|
|
With no users of the interface needing the readmask anymore, we can
remove it from the argument passed to these functions.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
This new libXfont API eliminates exposing internal X server symbols to
the font library, replacing those with a struct full of the entire API
needed to use that library.
v2: Use libXfont2 instead of libXfont_2
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
It is a modest performance improvement (2.7% on Intel), with the
significant downside that it keeps extra pixmap contents laying around
for 1000 BlockHandlers without the ability for the system to purge
them when under memory pressure, and tiled renderers don't know that
we could avoid reading their current contents when beginning to render
again. We could use the FB invalidate functions, but they aren't
always available, aren't hooked up well in Mesa, and would eat into
the performance gains of having the cache.
[ajax: rebased to master]
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
Fixes incorrect clipping for redirected windows which don't happen to be
located at the top left corner of the screen.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96742
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
The screen block and wakeup handlers are the only ones which provide a
well known ordering between the wrapping layers; placing these as
close as possible to the server blocking provides a way for the driver
to control the flow of execution correctly.
Switch the shadow code to run in the screen block handler so that it
now occurrs just before the server goes to sleep.
Switch glamor to call down to the driver after it has executed its own
block handler piece, in case the driver needs to perform additional
flushing work after glamor has called glFlush.
These changes ensure that the following modules update the screen in
the correct order:
animated cursors (uses RegisterBlockAndWakeupHandlers dynamically)
composite (dynamic wrapping)
misprite (dynamic wrapping)
shadow (static wrapping)
glamor (static wrapping)
driver (static wrapping)
It looks like there's still a bit of confusion between composite and
misprite; if composite updates after misprite, then it's possible
you'd exit the block handler chain with the cursor left hidden. To fix
that, misprite should be wrapping during ScreenInit time and not
unwrapping. And composite might as well join in that fun, just to make
things consistent.
[v2] Unwrap BlockHandler in shadowCloseScreen (ajax)
[v3] ephyr: Use screen block handler for flushing changes
ephyr needs to make sure it calls glXSwapBuffers after glamor finishes
its rendering. As the screen block handler is now called last, we have
to use that instead of a registered block/wakeup handler to make sure
the GL rendering is done before we copy it to the front buffer.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
Nice of FreePicture to take a void * instead of a PicturPtr so that
this error wasn't caught by the compiler.
Noticed when resetting the X server left a dangling pixmap around.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Current Mesa Git master checks that the EGL display actually supports
the API passed to eglBindAPI, which can only succeed after
eglInitialize.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96344
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Commit b64108fa ("glamor: Check for composite operations which are
equivalent to copies") failed to copy conditions from exaComposite which
ensure that the composite operation doesn't access outside of the source
picture.
This fixes rendercheck regressions from the commit above.
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Patch b64108fa305e956e4edaae9d53071ff0abee268e added a short cut that
identifies composite operations that can be performed with a simple
copy instead.
glamor_copy works in absolute coordinates, so the dx and dy values
passed in need to be converted from drawable-relative to absolute by
adding the drawable x/y values.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
A1 and A8 pixmaps are usually stored in the Red channel to conform
with more recent GL versions. When using these pixmaps as mask values,
that works great. When using these pixmaps as source values, then the
value we want depends on what the destination looks like.
For RGBA or RGB destinations, then we want to use the Red channel
for A values and leave RGB all set to zero.
For A destinations, then we want to leave the R values in the Red
channel so that they end up in the Red channel of the output.
This patch adds a helper function, glamor_bind_texture, which performs
the glBindTexture call along with setting the swizzle parameter
correctly for the Red channel. The swizzle parameter for the Alpha
channel doesn't depend on the destination as it's safe to leave it
always swizzled from the Red channel.
This fixes incorrect rendering in firefox for this page:
https://gfycat.com/HoarseCheapAmericankestrel
while not breaking rendering for this page:
https://feedly.com
v2: Add change accidentally left in patch for missing
glDisable(GL_COLOR_LOGIC_OP).
Found by Emil Velikov <emil.l.velikov@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63397
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
glamor_make_current is supposed to be called before any GL APIs.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
If the logic op gets left enabled, it overrides the blending
operation, causing incorrect contents on the display.
v2: Disable only on non-ES2, but disable even for PictOpSrc
v3: Found another place this is needed in
glamor_composite_set_shader_blend
v4: Remove change dependent on new glamor_set_composite_texture
API. This belongs in a different patch.
Found by Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
