Mark the stub intel_glamor_fd_from_pixmap() as inline to silence the
compiler warnings about unused function definitions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The trick is to make sure we consider the CapLast setting in the
direction the line is being drawn and adjust the inked pixels
accordingly.
Testcase: DrawSegments/hv0
Reported-by: Russell King
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have unfortunate fragmentation, e.g. a cursor is pinned in the
middle of an aperture, we can struggle to fit large objects, especially
fenced objects on gen2/gen3. We do have one last trick up our sleeves
that we can try: disable all of the outputs and cursors and try
submitting the batch in as pristine an aperture as we can arrange. We
can only hope that the subsequent restoration of the outputs is more
conducive to future batches (and so not lead us into continual flicker).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In case we have a hotplug at just the wrong time, we can fail a modeset
with a stale connector. Before attempting to recover, probe the kernel
for the current state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to fix the build without DRI3, we need to stub out the
functions not compiled in, such as intel_sync_fini().
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Check that we have the required Xorg headers for glamor if the user
requests --enable-glamor. There is a possiblity that the headers
mismatch as they don't have internal versioning, but this should catch
the majority of errors early on.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
glamor_pixmap_from_fd and glamor_fd_from_pixmap were added before
version 1.15.99.902, so check for that version before trying to use them.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Fabio Pedretti <fabio.ped@libero.it>
Instead of always including intel_uxa.h from intel.h, and including
uxa.h from some files directly, use intel_uxa.h directly from .c files
that have UXA-specific code in them.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
There aren't any symbols from uxa.h used in this file, remove the #include.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This makes the UXA-specific elements of intel_screen_private and a bit
of code in intel_driver covered under #if USE_UXA
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
intel_flush flushes any pending acceleration operations to the
hardware, just like intel_uxa_batch_submit does today except that it is
not uxa-specific.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This starts to separate uxa from the rest of the driver by renaming
uxa-specific functions and structs to make it clear which portions of
the driver are uxa-specific and which are common.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Eric Anholt <eric@anholt.net>
UXA and Glamor both share this function, so move it out of the UXA file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Make sure the pitch matches the current framebuffer.
Make sure there's a BO we can get at.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The pixmap private stride field is an exact duplicate of the devKind
field present in the core pixmap; eliminate the duplicate value and
replace references by calls to intel_pixmap_pitch.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
GetScratchPixmapHeader should only be used for local memory pixmaps,
as used by PutImage and friends. That's because when you free the
scratch pixmap header, it doesn't actually free the pixmap; instead,
it gets stuffed in pScreen->pScratchPixmap and any private data stored
on it will be left hanging around forever.
In the case of glamor, that private data includes all of the GL
state. Using that scratch pixmap later results in glamor getting
mightily confused as the pixmap and underlying objects do not match.
Avoid this by allocating pixmap headers explicitly for this purpose.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
intel_allocate_framebuffer has already made the call in each of these
code paths.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This creates wrappers to invoke glamor functions for pixmap_from_fd
and fd_from_pixmap when the driver is using glamor.
Signed-off-by: Keith Packard <keithp@keithp.com>
BO allocations for pixmaps must be aligned to the tile height, but at
some point the code was changed to align them to twice the tile
height. This overallocates pixmaps, wasting memory, but more
importantly, for buffers allocated by DRM and shared through DRI3, the
stricter alignment check causes sharing to fail.
From reading through the history of the code and related bugs, it
seems like this change was part of a set of changes trying to address
what turned out to be a kernel regression. Reverting this change
solves the DRI3 problem and saves a bit of memory for pixmap
allocations.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Let the kernel send these back to us so that DIX hears about them in
the usual way.
Mode setting while Present has a flip active will trigger an unflip
before the mode is changed. The event from that unflip will not get
processed before the mode switch is executed. Clearing the driver
queue at mode switch time will discard the connection between the
kernel event and the present callback so that DIX will never know that
the flip pixmap is idle.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
sna_trapezoids_precise.c:566:1: warning: unused function
'polygon_add_line' [-Wunused-function]
gen4_vertex.c:3093:1: warning: unused function
'gen4_choose_spans_vertex_buffer' [-Wunused-function]
Reported-by: Zdenek Kabelac <zkabelac@redhat.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
./xassert.h:24:9: warning: '__XASSERT_H___' is used as a header guard
here, followed by #define of a different macro [-Wheader-guard]
^~~~~~~~~~~~~~
./xassert.h:25:9: note: '__XASSERT_H__' is defined here; did you mean
'__XASSERT_H___'?
^~~~~~~~~~~~~
__XASSERT_H___
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
virtual.c:1081:6: warning: variable 'width' is used uninitialized
whenever 'if' condition is true [-Wsometimes-uninitialized]
if (clone->dst.mode.id == 0) {
^~~~~~~~~~~~~~~~~~~~~~~
virtual.c:1092:6: note: uninitialized use occurs here
if (width == clone->width && height == clone->height)
^~~~~
virtual.c:1081:2: note: remove the 'if' if its condition is always false
if (clone->dst.mode.id == 0) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
virtual.c:1079:11: note: initialize the variable 'width' to silence this warning
int width, height;
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In particular, the promotion of an active snooped bo into an uncached
linear GPU bo was being performed on a busy buffer and forcing a stall.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Another missed gcc warning resulting in a crash due to a missing
kgem_batch_space() initialisation.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
commit 6554cf0a69
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 11 12:22:17 2014 +0100
sna: Parse output options early during initialisation
rearranged the monitor query to before the num_outputs increment. The
result was that it choose the second output as the default and not the
intended first.
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=522500
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Current testing says that it is stable now... Let's see how long that
holds.
References: https://bugs.freedesktop.org/show_bug.cgi?id=79053
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the miSpans will continue to overdraw the Pixmap, it's final state
will no longer be that clear value. We need to be much more careful when
allowing that optimisation.
Reported-by: Tyler Foo <tftylerfoo@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=77074
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we turn off the screen, either at the user request or when
disabling an output, request that the associated backlight (which may
only be known to userspace) also be disabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A feature in recent kernels is to disambiguate between the meaning of
brightness=0, between disabling the the backlight entirely or setting
the lowest valid brightness. As such, we now have an extra knob in sysfs
to explicitly request that the backlight be turned off.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the caller will apply the damage afterwards, we do not need to do the
accumulation in the miSpans callbacks and it presumes that its damage is
unaltered.
References: https://bugs.freedesktop.org/show_bug.cgi?id=77074
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The intention is to be able to capture the assertion in the Xorg.0.log
(journald equivalent). At the moment, it is emitted to stderr which is
difficult to capture and defeats the goal of only asking the reporter to
upload one log file.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Unlike the other drm getters, GETBLOB insists on the exact length rather
than being told the buffer size.
Reported-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Requires running a PRIME setup with Intel loaded as the secondary GPU
and attempting to execute an empty glyph string.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
commit 30932a7b9d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Sep 8 12:41:06 2014 +0100
sna: Avoid u16 underflow when computing reserved batch space
relied on gcc a little to much to warn me when I missed initialising 'rem'
References: https://bugs.freedesktop.org/show_bug.cgi?id=77074
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we filled the batch exactly, then subtract -1 for the reserved
BATCH_BUFFER_END, it would underflow to a large value - convincing us
that we had sufficient room to stuff many, many more commands in.
However, all the callsites should be guarded by checking already that
they had sufficient space to emit at least one operation...
References: https://bugs.freedesktop.org/show_bug.cgi?id=77074
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Keith Packard