This eliminates a warning generated when miLineArcD is inlined and the
compiler can't figure out that edge1 and edge2 are always initialized
before being used.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This eliminates the duplicate declaration of dixGetGlyphs when
fontutil.h gets included after dixfont.h has defined GetGlyphs as
dixGetGlyphs.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
fixes:
In file included from rootlessWindow.c:51:0:
rootlessWindow.c: In function 'RootlessResizeWindow':
rootlessCommon.h:198:19: warning: declaration of 'w' shadows a parameter [-Wshadow]
WindowPtr w = pWin; \
^
rootlessWindow.c:1292:9: note: in expansion of macro 'HUGE_ROOT'
HUGE_ROOT(pWin);
^
rootlessWindow.c:1262:35: note: shadowed declaration is here
unsigned int w, unsigned int h, WindowPtr pSib)
^
In file included from rootlessWindow.c:51:0:
rootlessCommon.h:207:19: warning: declaration of 'w' shadows a parameter [-Wshadow]
WindowPtr w = pWin; \
^
rootlessWindow.c:1296:9: note: in expansion of macro 'NORMAL_ROOT'
NORMAL_ROOT(pWin);
^
rootlessWindow.c:1262:35: note: shadowed declaration is here
unsigned int w, unsigned int h, WindowPtr pSib)
^
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is already defined at the function entry.
fixes warning:
CC mivaltree.lo
mioverlay.c: In function 'miOverlayWindowExposures':
mioverlay.c:993:23: warning: declaration of 'pScreen' shadows a previous local [-Wshadow]
ScreenPtr pScreen = pWin->drawable.pScreen;
^
mioverlay.c:986:15: note: shadowed declaration is here
ScreenPtr pScreen = pWin->drawable.pScreen;
Signed-off-by: Dave Airlie <airlied@redhat.com>>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
By the time we get here we've already done CloseDownDevices, so on the
second regeneration you get:
Invalid read of size 4
at 0x43402A: RemoveDevice (devices.c:1125)
by 0x427902: xwl_seat_destroy (xwayland-input.c:568)
by 0x42649C: xwl_close_screen (xwayland.c:116)
by 0x4B7F67: CursorCloseScreen (cursor.c:187)
by 0x536003: AnimCurCloseScreen (animcur.c:106)
by 0x539831: present_close_screen (present_screen.c:64)
by 0x43E486: dix_main (main.c:351)
by 0x30D70206FF: (below main) (libc-start.c:289)
Address 0x980e1a0 is 64 bytes inside a block of size 904
at 0x4A07D6A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x434158: RemoveDevice (devices.c:1157)
by 0x42F77B: CloseDeviceList (devices.c:1017)
by 0x430246: CloseDownDevices (devices.c:1047)
by 0x43E3EB: dix_main (main.c:333)
by 0x30D70206FF: (below main) (libc-start.c:289)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
By the time we get here we've already been through FreeAllResources,
which has already torn down the RANDR objects, so on the second
regeneration you get:
Invalid read of size 4
at 0x51C6F0: RRCrtcDestroy (rrcrtc.c:659)
by 0x4285F5: xwl_output_destroy (xwayland-output.c:191)
by 0x426464: xwl_close_screen (xwayland.c:112)
by 0x4B7F77: CursorCloseScreen (cursor.c:187)
by 0x536013: AnimCurCloseScreen (animcur.c:106)
by 0x539841: present_close_screen (present_screen.c:64)
by 0x43E496: dix_main (main.c:351)
by 0x30D70206FF: (below main) (libc-start.c:289)
Address 0x4cc6640 is 0 bytes inside a block of size 728 free'd
at 0x4A07D6A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x51BCCF: RRCrtcDestroyResource (rrcrtc.c:689)
by 0x45CD91: doFreeResource (resource.c:872)
by 0x45DE56: FreeClientResources (resource.c:1138)
by 0x45DF06: FreeAllResources (resource.c:1153)
by 0x43E3BD: dix_main (main.c:321)
by 0x30D70206FF: (below main) (libc-start.c:289)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes a regression since a2a2f6e34b. I
missed this in testing on x86, because we never fail to allocate an
FBO. We do hit this path on VC4, though.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Without this, the context of another screen may be current, or no context
at all if glamor_egl_init failed for another screen.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Commit 90db5edf11 modified the signature of
StartPixmapTrackingProcPtr, so drivers implementing that need to use the updated
definition.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Header was added in 1dba5a0b19
but not in Makefile.am, resulting in missing header in the
distribution tarball.
Signed-off-by: Eric Anholt <eric@anholt.net>
glamor_name_from_pixmap and glamor_fd_from_pixmap return CARD16 and
CARD32 values via pointers. The current code uses uint16_t and
uint32_t which will probably be the same but it's safer to use the
datatypes as specified by the function.
Signed-off-by: Robert Ancell <robert.ancell@canonical.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Lots of the accel paths only make current once they start
doing someting, so a lot of them call the bail paths without
make current, which means on PRIME systems for example
we end up in the wrong context.
Add a prepare pixmap in the prepare fallback path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90667
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes slow text display in xdvi.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91260
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
These are dead since the glamor_copy.c replacement.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This hasn't been used since the format swap/revert stuff for pictures
was added back in 2012.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This function takes the start x/y and the destination's width/height,
so it only works if there's no transform. We could potentially
transform this box and take its bounds with some rounding, but this at
least gets us to read out enough data.
Note that this does the same overshoot on destination pictures with a
transform attached, but that seems unlikely to be used anyway.
v2: Add XXX comment for the commit message note (Suggested by Michel).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Dave Airlie <airlied@redhat.com> (v1)
The pixmap->picture is just the *last* picture attached to the pixmap,
so you'd potentially be looking at the wrong one when trying to
temporarily upload to avoid a composite fallback.
There's some trickiness in glamor_render.c when we're dealing with the
upload of a GLAMOR_MEMORY pixmap as both the source and mask using
different formats, where we smash the source's format to a new value
so that the mask can use the same uploaded bits. Dropping most of
that should be safe, since it will be uploaded as the source first, so
the smashed format will still be used.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
These functions aren't used by anything else, and are specific to the
temporary-upload-as-a-weird-format path of glamor_render.c, called
through glamor_upload_picture_to_texture().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
We don't need any of its weird handling of picture formats, since our
XV pixmaps don't have any pictures attached.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Attaching a picture to a pixmap doesn't change its GL format, so it
doesn't change how core rendering should be assigning colors to it.
(Imagine XCreatePixmap(), optional XCreatePicture(pixmap) with various
formats, XFillRectangle, XGetImage(). If the XGetImage results
changed, this would be wrong).
Fixes all failures in "rendercheck -t fill" and, as a result, the
remaining failures in "rendercheck -t blend -o src -f
a8r8g8b8,x2r10g10b10"
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
I'm amazed we've made it as far as we have without these checks: if
you made an unusual format picture that wasn't the normal a8r8g8b8 or
x8r8g8b8 or a8, we'd go ahead and try to render with it, ignoring that
the sampler would fetch totally wrong bits.
Fixes 260 tests in rendercheck -t blend -o src -f a8r8g8b8,x2r10g10b10
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
glamor_egl_init() was not undoing any of the init steps on init error,
add an glamor_egl_cleanup() function and use this both on error and on exit
to cleanup the various resources.
Even on a clean exit eglTerminate() was not being called, causing the fd
dup()-ed by eglInitialize() to stay open, call eglTerminate() from the new
glamor_egl_cleanup() to fix this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that it's always non-null when the pixmap is non-null, we don't
need so much of this. glamor_get_pixmap_private() itself still
accepts a NULL pixmap and returns NULL, because of glamor_render.c
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This avoids a lot of screwing around to attach our privates later. It
means that non-glamor pixmaps now gain 120 bytes of glamor privates on
64-bit (which has quite a bit of fixable bloat), and glamor pixmaps
take one less pointer of storage (not counting malloc overhead).
Note that privates start out zero-filled, which matches the callocs we
were doing when making our own privates, and in the case of an fb
pixmap that has a priv where it didn't before, the type ends up being
GLAMOR_MEMORY as we would want.
v2: Clarify that the GLAMOR_MEMORY enum must be 0 (as it was
previosuly), so that the new pixmap private behavior is as
expected. Suggested by keithp.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Keith Packard <keithp@keithp.com>
It died as of keithp's new glyphs code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
We're always creating ~230 atoms at startup, might as well tune it so we
don't hit the realloc path before Dispatch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This extension allows clients to opt out of the implicit glFlush on
context release, which is quite nice for performance for clients using
multiple contexts. The server doesn't really need to be aware of the
client's decision, at least for direct contexts, but it does need to not
reject the context attribute out of hand.
This patch won't do anything unless built against a Mesa that defines
the __DRI2_FLUSH_CONTROL extension (and a new enough glxext.h, but
that's been there since 10.3 at least).
Reviewed-by: James Jones <jajones@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This gets you nice things like core contexts when using Xvfb.
Also, no, MESA_copy_sub_buffer is not enabled automatically.
Reviewed-by: James Jones <jajones@nvidia.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Removes the last cpp conditional on ROOTLESS from dix code.
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This is effectively a revert of 7b506fdc84
except the coding style reindent broke that. The code makes no sense in
any case. drawable can never be null since it's the first member of
WindowRec, and we're never called with a null window. Neither can it be
an UNDRAWABLE_WINDOW since those are InputOnly windows; the rootless
code does not set the root window to either UNDRAWABLE or InputOnly, so.
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
It's not a lot of code, and if you're doing things to the core that
affect rootless you should be alerted early.
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
ROOTLESS_RESIZE_GRAVITY is an optimization, so let's default it to off
unless the backing window system is known to support it.
ROOTLESS_PROTECT_ALPHA looks like it has different values for xquartz
and win32, but hilariously rootlessGC.c merely checks if it is defined,
not what the value is. It's effectively the more conservative path
anyway, so let's just turn it on.
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Also remove vidmodeproc.h from the SDK since no drivers are using it.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
