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 should be useful for glamor development, so you can test both
paths (which are significantly different, and apparently
glamor_gradient.c was broken on GLES2 as of the import).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The difference between the two is that XF86 has the clip helper that
lets you upload less data when rendering video that's clipped. I
don't think that's really worth the trouble, especially in a world of
compositors, so I've dropped it to get to shared code.
It turns out the clipping code was broken on xf86-video-intel anyway.
To reproduce, run without a compositor, and use another window to clip
the top half of your XV output on the glamor XV adaptor: the rendering
got confused about which half of the window was being drawn to.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
No code modifies it at runtime, and it's common to store string
literals to it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
I want to expose this from Xephyr as well, both to be able to test XV
changes rapidly, and beause the XV passthrough to the host's overlay
really doesn't work out well when we glXSwapBuffers() over the
colorkey.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Now that we don't have to worry about the generic adaptors code,
there's no need to have a list of pointers to different sets of
adaptors.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
These were field-for-field identical, so we can just typedef them to
be the same, and memcpy their contents.
v2: Fix missed strdup().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The core rendering paths all use the glamor_program fill functions now
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This provides glamor_solid_boxes and glamor_solid using regular GC
operations instead of calling directly to underlying rendering
functions. This will allow the old rendering code to be removed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This copies the stipple to a 8bpp pixmap and uses that to paint the
texture from.
v2: Create deep stipple pixmap without GLAMOR_CREATE_FBO_NO_FBO
v3: Fix stipple origin sign (matches tiles now). Track changes
to original stipple with damage. This isn't required by the
X spec, but java appears to depend on it, so we'll just do it.
When Glamor switches to 8bpp bitmaps, we'll be able to render
directly from them and not need this anymore.
v4: Review comments from Eric:
* Remove stray whitespace change
* Avoid "large" pixmap for stipple by using GLAMOR_CREATE_NO_LARGE
* Wrap to 80 columns
v5: Don't crash when stipple damage tracker is destroyed
The stipple damage tracker is automatically destroyed when the
associated stipple pixmap is destroyed. When this happens, just
clear the pointer from the GC rather than calling
glamor_invalidate_stipple; that function would call
DamageUnregister on the now invalid stipple damage pointer and
crash.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This makes sure the pixelization for dashed lines matches non-dashed
lines, while also speeding them up.
v2: Switch to glamor_make_current
v3: Create dash pattern pixmap without GLAMOR_CREATE_FBO_NO_FBO
v4: Adopt suggestions from Eric's review:
- Drops power-of-two alignment of our line vertex data, simplifying
the code.
- Stops reading from the VBO. While on keithp's and my machines the
VBO is mapped cached, on many implementations it will be mapped WC,
making those reads extremely expensive.
- Style fixes (line wrapping, spaces around operators).
v5: Adopt suggestions from Markus' review:
- Use max when computing zero-width dashed line length.
Don't open code max here.
- Embed CoordModePrevious into VBO writing for dashed lines
Instead of pre-computing the coord mode previous results, just
embed this in the loop which fills the vertex buffer. Saves
re-writing the request buffer, and shortens the code a bit
v6: Export glamor_destroy_gc for UXA
UXA needs to call glamor_destroy_gc from its GCFuncs, so export
it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
GL lines are nearly X compliant; you just need to fill in the last
pixel when the client hasn't requested CapNotLast.
v2: switch to glamor_make_current
v3: use miPolylines instead of custom glamor fallback path. Wrap
code to 80 columns.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This uses the same shaders as glamor_poly_glyph_blt.
v2: Wrap some long lines (changes by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Paints with textures, using a temporary buffer for overlapping copies
Performs CPU to GPU transfers for pixmaps in memory. Accelerates copy
plane when both objects are in the GPU. Includes copy_window
acceleration too.
v2: Use NV_texture_barrier for non-overlapping copies within the same
drawable
v3: Switch to glamor_make_current
v4: Do overlap check on the bounding box of the region rather than
on individual boxes
v5: Use Eric Anholt's re-written comments which provide a more accurate
description of the code
v6: Use floating point uniform for copy plane bit multiplier. This
avoids an int to float conversion in the copy plane fragment shader.
Use round() instead of adding 0.5 in copy plane. round() and +0.5
end up generating equivalent code, and performance measurements
confirm that they are the same speed. Round() is a bit clearer
though, so we'll use it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
There's no reason to use a pointer here, it just wastes time.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
These offer a simpler and more efficient means for temporarily
transitioning to CPU-accessible memory for fallback implementations.
v2: Do not attempt fallbacks with GLAMOR_DRM_ONLY pixmaps
glamor cannot transfer pixels for GLAMOR_DRM_ONLY pixmaps using
glReadPixels and glTexSubImage2D, and so there's no way to perform
fallback operations with these pixmaps.
v3: Clear ->pbo field when deleting the PBO. Otherwise, we'd reuse
the old name next time we fall back on the pixmap, which would
potentially conflict with some other pixmap that genned a new
name, or just do a lazy allocation of the name (compat GL context,
like we currently use) or error out (core GL context, like we hope
to use some day). Also, style fixes. Changes by anholt, acked by
keithp.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
miZeroLine allocates enough space to draw a line spanning the entire
width/height of the target drawable. When drawing multiple shorter
lines, this leaves most of the space in that buffer unfilled. Let
multiple lines be drawn into the buffer if there is plenty of space.
Speeds up glamor fallback zero-width lines:
Before
6000000 trep @ 0.0020 msec (508000.0/sec): 1-pixel line
6000000 trep @ 0.0020 msec (492000.0/sec): 10-pixel line
6000000 trep @ 0.0023 msec (427000.0/sec): 100-pixel line
4000000 trep @ 0.0035 msec (282000.0/sec): 500-pixel line
After:
600000000 trep @ 0.0000 msec (43400000.0/sec): 1-pixel line
140000000 trep @ 0.0001 msec (13000000.0/sec): 10-pixel line
16000000 trep @ 0.0008 msec (1300000.0/sec): 100-pixel line
4000000 trep @ 0.0038 msec (261000.0/sec): 500-pixel line
(500 pixel lines do not change in performance because the buffer can
only one one of them.)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This allocates span data for multiple arcs and draws the
whole set in one call, rather than doing them one at a time. For
modern hardware, this is a significant performance improvement.
v2: Limit the number of spans per buffer to 4M to avoid
integer overflow in computing the malloc size.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Instead of forcing drivers to figure out when to call miZeroPolyArc,
have miPolyArc call that when possible.
This involved renaming the existing miPolyArc call to miWideArc and
creating a new miPolyArc wrapper function as miZeroPolyArc falls back
to miWideArc when the arc is too large to be drawn with the zero-width
code (ellipses larger than 800x800).
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Instead of requiring all drivers to figure out which mi function to
call for each of the four cases, create a single wrapper in mi that
handles them correctly. Now drivers can simply use miPolylines in all
cases.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glx will sometimes select a non-root visual, deal with that by
creating a suitable colormap and using that instead of attempting to
use the default colormap.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
mieq.c:520:9: error: void function 'mieqProcessDeviceEvent' should not return a value [-Wreturn-type,Semantic Issue]
return 0;
^ ~
1 error generated.
Regression-from: 9fb08310b5
Found-by: Tinderbox
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Once a device is disabled, it doesn't have a sprite pointer anymore. If an
event is still in the queue and processed after DisableDevice finished, a
dereference causes a crash. Example backtrace (crash forced by injecting an
event at the right time):
(EE) 0: /opt/xorg/bin/Xorg (OsSigHandler+0x3c) [0x48d334]
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x37fcc0f74f]
(EE) 2: /opt/xorg/bin/Xorg (mieqMoveToNewScreen+0x38) [0x609240]
(EE) 3: /opt/xorg/bin/Xorg (mieqProcessDeviceEvent+0xd4) [0x609389]
(EE) 4: /opt/xorg/bin/Xorg (mieqProcessInputEvents+0x206) [0x609720]
(EE) 5: /opt/xorg/bin/Xorg (ProcessInputEvents+0xd) [0x4aeb58]
(EE) 6: /opt/xorg/bin/Xorg (xf86VTSwitch+0x1a6) [0x4af457]
(EE) 7: /opt/xorg/bin/Xorg (xf86Wakeup+0x2bf) [0x4af0a7]
(EE) 8: /opt/xorg/bin/Xorg (WakeupHandler+0x83) [0x4445cb]
(EE) 9: /opt/xorg/bin/Xorg (WaitForSomething+0x3fe) [0x491bf6]
(EE) 10: /opt/xorg/bin/Xorg (Dispatch+0x97) [0x435748]
(EE) 11: /opt/xorg/bin/Xorg (dix_main+0x61d) [0x4438a9]
(EE) 12: /opt/xorg/bin/Xorg (main+0x28) [0x49ba28]
(EE) 13: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x37fc821d65]
(EE) 14: /opt/xorg/bin/Xorg (_start+0x29) [0x425e69]
(EE) 15: ? (?+0x29) [0x29]
xf86VTSwitch() calls ProcessInputEvents() before disabling a device, and
DisableDevice() calls mieqProcessInputEvents() again when flushing touches and
button events. Between that and disabling the device (which causes new events
to be refused) there is a window where events may be triggered and enqueued.
On the next call to PIE that event is processed on a now defunct device,
causing the crash.
The simplest fix to this is to discard events from disabled devices. We flush
the queue often enough before disabling that when we get here, we really don't
care about the events from this device.
X.Org Bug 77884 <http://bugs.freedesktop.org/show_bug.cgi?id=77884>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When a flip (or unflip) is pending and a flip request comes in, leave
it queued until the pending flip completes and then execute it.
This fixes a bug where an application submitting back-to-back
present_pixmap requests for sequential frames would alternate between
flipping and copying as the pending flip would cause the new
present_pixmap request to not use a flip.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Frank Binns <frank.binns@imgtec.com>
The initial state of the cursor is set to disabled but this was
never be re-disabled during X server reset. This meant any
application run after an X server reset would have the cursor
displayed even if it hadn't requested this to be the case.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The server is leaking a pixmap (created by CreateDefaultStipple()) on
reset. The leak is caused by some X Server graphics contexts not being
freed on reset by the machine independent cursor code in the server,
which in turn is caused by the cursor cleanup code
(miSpriteDeviceCursorCleanup()) not being called.
Ensures the DeviceCursorCleanup() function is called when the associated
input device is closed on server reset.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The new current cursor was being referenced twice, resulting in a
memory leak when the current server generation ended.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Call FreePixmap() instead of free() to destroy the screen pixmap in
fbCloseScreen().
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is so that drivers can do a runtime check that Present is available,
similar to existing runtime checks performed by the drivers for DRI.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is so that drivers can do a runtime check that DRI3 is available,
similar to existing runtime checks performed by the drivers for DRI and
DRI2.
v2: Only add DRI3 to the list if the module was actually built into the
server (Mark Kettenis).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>
Signed-off-by: Keith Packard <keithp@keithp.com>
To make X -configure work properly, the output of fixup_video_driver_list()
should be in order of preference. Otherwise, the config file may use
the incorrect driver for some devices.
In particular, the drivers that work for all (or many) devices need to be
last in the list. Since the modesetting driver works for many devices,
it needs to be considered a fallback driver.
Signed-off-by: Søren Sandmann <ssp@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The easiest way to check for the version of an extension is to send the maximum
possible version numbers in the QueryVersion request. The X server overflows on
these as it assumes you will send a reasonable version number.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The explicit release requests were added in 1.3.0, don't try to build
against older.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Commit f37a469134 removed this from
xwin-config.h.in for some reason, but it is used.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Update for __glXLastContext -> lastGLContext.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
DontZap off is the default anyway, don't mention it specifically to avoid
confusion
X.Org Bug 71113 <http://bugs.freedesktop.org/show_bug.cgi?id=71113>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The easiest way to check for the version of an extension is to send the maximum
possible version numbers in the QueryVersion request. The X server overflows on
these as it assumes you will send a reasonable version number.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>