No functional changes. Apparently spec has been changed
the valid table showing 0x192A as Server GT4
while 0x193A is Server GT4e.
Libdrm and Mesa already have this right. So let's fix the ref here.
Kernel is also fixed with commit 5390974f981907.
"drm/i915: Update SKL SRV GT4 pci ids reference."
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This commit adding all known marketing names for latest gen9 platforms.
v2: On top of simplified generic string names.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Modern Intel (R) platforms with integrated graphics comes with common
names varying the range numbers. So instead of listing all supported
platforms let's start using the generic marketing strings without
the numbers.
And for the specific board we list it's actual marketing name if
available on detection.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
If we are not careful, we may process an unflip in the middle of
resizing the frontbuffer - when the ScreenPixmap state is ill-defined.
First flush all the pending flip events, cancel any residual unflips,
then update the screen pixmap. This should be enough to close the race.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98855#c11
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Same ids from kernel's
commit 8363e3c3947d0e22955f94a6a87e4f17ce5087b4
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Thu Nov 10 17:23:08 2016 +0200
drm/i915/glk: Add Geminilake PCI IDs
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
commit 17213b74fd7fc4c4e2fe7a3781e7422dd482a0ab
Author: Michel Dänzer <michel.daenzer@amd.com>
Date: Tue Jun 21 16:44:20 2016 +0900
xfree86/modes: Remove xf86RandR12CrtcGetGamma
removed the randr_crtc->palettes allocation and initialisation causing a
later dereference of the gamma table to crash. Looks like that was just
ABI misuse.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98855
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have a SHM pixmap, we only track rendering via the CPU bo for
synchronisation with the client.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the xlib/xcb library has pulled events from the fd, then a poll on
that fd will block until new events arrive. If none do, we fail to
process the currently waiting events in a timely fashion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The most common cause of SETCRTC failure is if the connectors disappear.
Force the reprobe on these after a failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we find that we're sharing the cursor, we wind up bailing out of
__sna_get_cursor() before the fb_to_cursor transform is computed. For
rotated displays, this can prevent the hotspot transformation from
happening properly, so the cursor's visible position won't match the
software's idea of where it is.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
sna_cursor_set_position() requires an already computed cursor
transformation matrix in order to determine whether the cursor is
visible. This is computed in __sna_get_cursor() which is currently only
called for visible cursors - i.e. we were using uninitialised state.
Reported-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As a modeset may adjust the rotation or the transform of the cursor, we
may need to recompute the cursor image afterwards.
Reported-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Caught by gcc-6 as:
brw_eu_emit.c:180:49: warning: logical 'and' of equal expressions [-Wlogical-op]
if (reg.file == BRW_ARCHITECTURE_REGISTER_FILE &&
reg.file == BRW_ARF_NULL)
return;
Change uses 'reg.nr' test for 'BRW_ARF_NULL'.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Always show the image, even if the bo doesn't appear to change as the
client may have put fresh data in the shared buffer and repositioned the
image.
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xf86XVClipVideoHelper wants to measure from the origin of the target
extents to the clip in order to determine the right offset into the
source.
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we flip to a bo, the kernel will flush it from the CPU write domain
and so afterwards we need to do a new set-domain to mark up a subsequent
CPU write (and flush before another flip).
References: https://bugs.freedesktop.org/show_bug.cgi?id=95414
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we do flip to restore the bo after the current Window is destroyed,
we should not request that we send an event back to the client.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When the pending flip is queued, we update all the Windows to use the
next bo as their rendering target. However, that bo is not yet the
scanout until the future flip is performed. If the current fullscreen
Window is destroyed, we still must allow that flip to proceed or else
the old bo is left on the scanout.
And yes, this is indeed a fix to one of the debug patches that intended
to detect the error causing #93844. Irony.
Fixes: 7817949314 ("sna/dri2: Avoiding marking a pending-signal on a dead Drawable")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93844
Reported-by: Diego Viola <diego.viola@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As a backup in case DRI2 is disabled due to the presence of vgaarb, make
sure we have DRI3 loaded.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When finding the per-connector backlight interface, we have to take a
copy of the interface name for later use, as in this case it is not
constant.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Modern kernels include a link from the sysfs connector directory to the
backlight interface on that connector. Try to find that link first as
this should allow us to enable backlight interfaces on connectors other
than the presumed solitary panel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We start off the system with the screens blanked, waiting the first
dixSaveScreen unblank, where we then apply the accumulated modesets.
This means we have to allow that even if Option DPMS off, and so we
restrict the Option to only enable DPMS (then once enabled they will not
turn off).
References: https://bugs.freedesktop.org/show_bug.cgi?id=98375
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The defacto standard is that the screensaver only blanks the screen but
keeps the outputs alive. We differ by actually disabling the CRTC when
the screen saver kicks in (to save power), however this circumvents
Option "DPMS".
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98375
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we detect a change in the output status, ignore the residual mode on
the CRTC. We use this CRTC mode during inheritance to provide
continuity and to make xrandr look neat we ensure that the mode is
included in the output list. However, following a hotplug event the
current mode may now be invalid and needs to be pruned.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the kernel can provide us with the exact connector that needs
reprobing following a hotplug event, use it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Output_check_status() should return a false if it detects
that the connector mode list has changed so that sna_mode_discover
can reprobe.
Fixes: eb01cc549d (sna: Refresh mode list if the kernel updates)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
If the kernel changes its list of modes, make sure we update. (This is a
losing battle since X will add whatever modes it finds from the EDID
despite what the kernel is telling it.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As found by Adam Jackson, we can perform the masking of the planemask on
the user buffer and so avoid hitting the fallback paths, so long as we
have no 24bpp Pixmaps.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
At the kernel level, threads and processes are identical - they each get
a fair share of CPU time. From this we can surmise the cause of any
variation between threads and processes. If the threads are balanced
(each thread completing the same number of requests), but the processes
have unbalanced numbers, we know that X is not as fair.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the middle of a composite op, we take the opportunity to note when a
fill clears the entire surface - and mark up the surface as clear. This
includes marking it as all damaged, to the surprise of the upper layer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
commit c446a7ccc7
Author: Wayne Boyer <wayne.boyer@intel.com>
Date: Wed Nov 18 10:39:42 2015 -0800
Add Kabylake PCI IDs
missed adding the GT information, leaving bxt,kbl using only generic
acceleration.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
