Replace the cast+deref with memcpy() so that we don't upset
the compiler's strict aliasing rules.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Just access the xGlyphInfo members directly to avoid the
compiler getting upset about strict aliasing violations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
../src/intel_device.c: In function ‘__intel_open_device__pci.isra.6’:
../src/intel_device.c:321:25: warning: ‘%s’ directive writing up to 255 bytes into a region of size 247 [-Wformat-overflow=]
sprintf(path + base, "%s", de->d_name);
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Use an empty {} as the terminator in intel_device_match[] to avoid
the warning about missing initlizers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Duplicate a bit of code in FbDoLeftMaskByteRRop() switch statement
to avoid the fall through.
And while at it sort the cases based on the left byte and length.
Makes the pattern matcher in my brain much happier.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Refactor the BR13 color depth setup to common helper. This
eliminates a bunch of implicit fall through warns.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
gcc doesn't like extra stuff in the fall through comments.
Replace them with the standard form.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
../src/sna/sna_composite.c:567:11: warning: variable ‘sx’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
int16_t sx = src_x + tx - (dst->pDrawable->x + dst_x);
^~
etc.
I had a quick look at a few of the cases and they seemed fine to me,
so feels like gcc just being dense.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
If we change scanout status (i.e. whether or not this flip chain may be
presented directly on the CRTC), throwaway the previous back buffer
cache as those buffers may not be suitable for presentation.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=111197
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the backbuffer is stale (i.e. the client didn't call DRI2GetBuffers
before swapping) the front/back bo may not be distinct. Move the
assertion for a valid swap after the handling of a stale swap so that
the assertions are more robust for a client error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111197
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Check for a stale backbuffer (the client didn't call DRI2GetBuffers
between DRI2SwapBuffers) before asserting so that we should be
more resilient with asserts enabled for client errors.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111197
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mixing I915_TILING_Y and the blitter is painfully slow, so we need to
take use of I915_TILING_Y into more prominent consideration and even
force a ring switch in case it is being used.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Probe the GAMMA_LUT/GAMMA_LUT_SIZE props and utilize them when
the running with > 8bpc.
v2: s/sna_crtc_id/__sna_crtc_id/ in DBG since we have a sna_crtc
v3: Fix the vg "bluered" typo (Mario)
This time I even build tested with vg support
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Generalize the code that parses the plane properties to be useable
for crtc (or any kms object) properties as well.
v2: plane 'type' prop is enum not range!
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Once we've switched to using the swcursor (possibly
due to the cursor ioctl failing) we currently keep
using the swcursor until the modeset.
That's not particularly great as the swcursor has several
issues. Apart from the (presumably expected) flicker,
the cursor also tends to leave horrible trails behind
around dri2/3 windows (happens with tearfree at least).
To avoid some of that let's try to switch back to the hwcursor
a bit sooner. We can do that neatly via the convenient swcursor
block handler.
v2 [ickle]: Apply the restoration after the screen update is complete.
v3 [vsyrjala]: Push it back to restore_swcursor and remove the
fullscreen redraw -- prevents terrible flickering in v2!
References: https://bugs.freedesktop.org/show_bug.cgi?id=106935
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Apparently we never take this path or else it would have failed before
(we don't take it as we prefer render for these chipsets).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Presumably this only matters for i686 because amd64 implies sse2, but:
BUILDSTDERR: In file included from gen4_vertex.c:34:
BUILDSTDERR: gen4_vertex.c: In function 'emit_vertex':
BUILDSTDERR: sna_render_inline.h:40:26: error: inlining failed in call to always_inline 'vertex_emit_2s': target specific option mismatch
BUILDSTDERR: static force_inline void vertex_emit_2s(struct sna *sna, int16_t x, int16_t y)
BUILDSTDERR: ^~~~~~~~~~~~~~
BUILDSTDERR: gen4_vertex.c:308:25: note: called from here
BUILDSTDERR: #define OUT_VERTEX(x,y) vertex_emit_2s(sna, x,y) /* XXX assert(!too_large(x, y)); */
BUILDSTDERR: ^~~~~~~~~~~~~~~~~~~~~~~~
BUILDSTDERR: gen4_vertex.c:360:2: note: in expansion of macro 'OUT_VERTEX'
BUILDSTDERR: OUT_VERTEX(dstX, dstY);
BUILDSTDERR: ^~~~~~~~~~
The bug here appears to be that emit_vertex() is declared 'sse2' but
vertex_emit_2s is merely always_inline. gcc8 decides that since you said
always_inline you need to have explicitly cloned it for every
permutation of targets. Merely saying inline seems to do the job of
cloning vertex_emit_2s as much as necessary.
So to reiterate: if you say always-inline, it won't, but if you just say
maybe inline, it will. Thanks gcc, that's helpful.
In case udev_monitor_get_device() itself does not handle being
interrupted, go around the loop again. Daniel Vetter discovered this
interesting quirk during igt testing of kms_leases.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The various clut handling functions like a setup
consistent with the x-screen color depth. Otherwise
we observe improper sampling in the gamma tables
at depth 30.
Therefore replace hard-coded bitsPerRGB = 8 by actual
bits per channel scrn->rgbBits. Also use this for call
to xf86HandleColormaps().
Tested for uxa and sna at depths 8, 16, 24 and 30 on
IvyBridge, and tested at depth 24 and 30 that xgamma
and gamma table animations work, and with measurement
equipment to make sure identity gamma ramps actually
are identity mappings at the output.
v2: Also deal with X-Server 1.19 and earlier, which as of
v1.19.6 lack a fix to color palette handling and can
not deal with depths/bpc > 24/8 bpc. On < 1.20 we skip
xf86HandleColormaps() setup at > 8 bpc. This disables
color palette handling on such servers at > 8 bpc, but
still keeps RandR gamma table handling intact.
Tested on 1.19.6 and 1.20.0 to do the right thing.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The kernel may keep the old connector id around so that userspace can
gracefully switch it off, which means that on detecting a topology
change (a new id for an old connector path), we must do a SetCRTC to
release the old resources.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106250
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
OpenBSD, FreeBSD and NetBSD don't contains file byteswap.h.
Used specifics of them.
Fixes: 746ab3bb13 (sna: Added AYUV format support for textured and sprite video adapters.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109268
CC: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
If we do not have a mode (and bo) enabled on the crtc, then trying to
restore that bo ends up in a NULL pointer dereference.
Reported-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
v2: Renamed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV8888.
Added comment about AYUV byte ordering in Gstreamer.
v3: Removed sna_composite_op flags related change to the separate patch.
v4: Fixed review comments, done code refactoring
v5: Fixed following review comments:
- Fixed comment in shader code for ayuv kernel.
- Fixed naming to VIDEO_AYUV_BT601/BT709 for ayuv kernels.
- Removed duplicate gen9_kernel parameter, left from previous patches
- Added colorspace handling for new AYUV kernel
- Fixed naming of sna_copy_packed_data_ayuv to sna_copy_ayuv_data
- Started using standard bswap_32 function for byte swapping in sna_copy_ayuv_data
- Removed redundant code in sna_copy_ayuv_data so that it looks more neat
- Fixed XVIMAGE_AYUV structure initialization to contain proper byte sequence for GST
- Fixed bogus comment about subsampling for DRM_FORMAT_XYUV8888
- Fixed AYUV advertisement for all platforms
- Removed unnecessary RGB888 declaration.
v6:
- Fixed surface format not to use alpha as supposed
- Now doing byte swapping always during copy
- Changed hack, required for GST to work to be at one place
- Fixed invalid sampling values for XVIMAGE_AYUV
- Fixed sprite format checking order and images_ayuv definition.
v7:
- Removed reverse_bytes bool parameter, now swapping bytes
for XYUV unconditionally both for textured and sprite modes.
v8:
- Added gen9_images structure, in order to expose AYUV format to
proper platforms.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With the extra video kernels we already ran out of bits in
the flags. To tackle that let's just split out the
wm_kernel to its own thing.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can't output color index formats with the render engine,
so let's disable the textured Xv adaptor for depth 8.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Texured Xv works just fine with depth 30. Allow it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
With the colorkey setup fixed the sprite Xv adaptor works just
fine with depth 30.
With depth 8 there is one remaining problem with the usage of
the LUT for gamma vs. C8, but that is purely a kernel issue.
Let's allow both depth 8 and depth 30 with the sprite Xv
adaptor.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Set up the colorkey correctly for depth != 24. For 8bpc we
need to replicate the same key value into each channel, for
depth 15/16 we need to mask off the unused low bits in each
channel, and for depth 30 we just use the 8 msbs of each channel
as the colorkey register can't hold the full 10 bits.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
'debug' is a reserved option name since meson 0.48. So we
must rename our own debug option to something else. Let's
go with 'internal-debug'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If Xinerama is enabled, RandR is disabled and calling into RR functions
merely explode, so don't.
Reported-by: Mariusz Białończyk <manio@skyboo.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108495
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sometimes the write simply do not land until later, requiring us to be
very careful in how we perform domain tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Import the kernel's i915_pciids.h, up to
commit d0e062ebb3a44b56a7e672da568334c76f763552
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Fri Aug 3 16:27:21 2018 -0700
drm/i915/cfl: Add a new CFL PCI ID.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add more Coffeelake PCI IDs based on the following kernel patch:
commit c99d7832dcd7423ba352386107118b9bd8b83158
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Wed Dec 20 10:29:19 2017 -0800
drm/i915/cfl: Adding more Coffee Lake PCI IDs.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
It's 32bpp, depth 24 (for x8r8g8b8 pixel format), not 32 for everything.
Just to be on the safe side, pick the more common x8r8g8b8 format.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Looks like we need a libdrm dep on intel_drv. Build fails for me on
Arch.
In file included from ../src/intel_device.c:51:
/usr/include/xf86drm.h:40:10: fatal error: drm.h: No such file or directory
#include <drm.h>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
On SKL+ the dst colorkey is enabled on the primary plane instead of the
sprite plane. That means the restriction of scaling vs. keying doesn't
actually apply here as we never scale the primary. So let's remove
the requirement of having XV_ALWAYS_ON_TOP enabled to get hw scaling.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
When we're trying to reinstate the colorkey we might fail on account of
the plane still being enable with a configuration that prevent the
use of colorkey. This happens easily with NV12 since the plane scaler
required by even unscaled NV12 is not compatible with colorkey.
To work around the problem let's try disabling the plane first, then
re-enable the colorkey, and finally we will try to re-enable the plane.
The plane re-enable may fail, in which case we'll head to the GPU
scaling fallback path. The cost is a flash of the colorkey when the
plane blink off and then back on.
Help me atomic ioctl, you're my only hope!
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even unscaled NV12 needs the plane scaler on SKL+, so when
unscaled NV12 setplane fails we should still take the GPU
scaling fallback path.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Starting from ~KBL planes can do NV12. Let's make use that
capability in the sprite Xv adaptor.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Not all sprite planes support RGB565. Insrtead of hardcoding which
platforms have it let's ask the kernel instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On SKL+ dst color keying only works between the first sprite and the
primary. We probably wante the first Xv port to be the first sprite
plane so that the user gets working colorkeying for the port that is
most likely to be used first. No way to get dst colorkeying with the
other ports :(
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow the client to select between BT.601 and BT.709 via the
XV_COLORSPACE port attribute with the textured Xv adaptor as well.
Since the BT.601 coefficients are currently hardcoded in the
yuv->rgb shader, let's just add a mostly duplicated shader with
hardcoded BT.709 coefficients instead. Not the most elegant solution
but avoids having to touch any state setup etc.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ville Syrjälä
Chris Wilson
Adam Jackson
Mario Kleiner
Sergii Romantsov
Stanislav Lisovskiy
Liwei Song