Be neat and tidy in case we are shutdown but the server is not
regenerated (e.g. a hot-unplug).
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adam Jackson notes that what appeared to be my paranoid ramblings in SNA
actually served a purpose - it prevents a server crash following
server regen if an indirect client happened to be running at the time
(e.g. LIBGL_INDIRECT_ALWAYS=1 glxgears).
Reported-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On gen6+, bo are expected to be LLC by default. However, as using the bo
for the scanout causes it to be moved into the uncached domain, this
assumption is then false and we should release the bo back to the system
rather than spread the uncached buffers around. The most common
allocator of scanouts is for pageflipping which are already non-reusable
due to the DRI2 export, so there should actually be little impact.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Libdrm's possible_clones is a mask of encoders. Xorg's possible_clones
is a mask of outputs, so we just can't do the following:
output->possible_clones = kencoder->possible_clones;
This is a problem on Haswell because, at least with the current
patches floating on the mailing list, there is more than one connector
per encoder.
This patch writes the code to properly translate libdrm's encoder mask
into Xorg's output mask.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As intel_crtc_on() depends upon the current value for determining if the
pipe is active, we can only change the value afterwards.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the Ubuntu xserver it is apparently possible for the Screen to be
deleted prior to being fully initialised. Make sure we don't crash in
that situation!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55346
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In light of the discussion on how to add stereo modes it was revealed
that we would happily add modes with unknown and unhandled strange
flags. Adam Jackson mentioned that he has plans to fix that with some
upcoming work, but as a first step we can simply eradicate them whilst
pondering how to support the stereoscopic vision of the future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This adds support for pixmap tracking and scanout of
alternate pixmaps.
v2: do dirty updates after uxa block handler, check if kernel
can flush vmap for us so we don't have to.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The automatic selection may not correspond with the correct backlight
(such as in a multi-gpu, multi-panel device) or the user may simply
prefer another control interface. This allows them to override the
chosen interface using
Option "Backlight" "my-backlight"
to specify '/sys/class/backlight/my-backlight' as the interface to use
instead.
Suggested-by: Alon Levy <alevy@redhat.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=29273
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even if page-flipping itself is disabled, we still want to allow the
client to schedule wakeups for some future vblank which requires
listening to the kernel vblank notifications.
Reported-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51699
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Upon a VT switch, we set the desired modes and turn off the DPMS on any
unused output. Make this explicit so that we always maintain consistency
between the kernel and X's list of enabled CRTCs.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50772
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Copy the current framebuffer for smooth wayland->gdm handoff.
This has been hanging around in Fedora for too long now, and we've
dropped the feature a few times, and yes I know the Simpsons did it^W^W^W
SNA does it.
I've updated the code to have some of the better fixes from nouveau.
I've no idea who wrote this code either, krh or ajax. [ickle: The
earliest version I've found had krh's fingerprints on it, though it may
still have been a joint effort.]
Signed-off-by: Dave Airlie <airlied@redhat.com>
[ickle: improve error handling, only copy the fb during initial takeover]
Regression from commit 3f3bde4f0c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu May 24 11:58:46 2012 +0100
uxa: Only consider an output valid if the kernel reports it attached
When backporting from SNA, a key difference that UXA does not track DPMS
state in its enabled flag and that a DPMS off CRTC is still bound to the
fb. So we do need to rescan the outputs and check that we have a
connector enabled *and* the pipe is running prior to emitting a scanline
wait.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50668
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Unifies available options for both UXA and SNA drivers, and
moves them into a common header file, intel_opts.h.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Same change for intel_display.c and sna_display.c.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To support easy buffer exchange at glamor layer, glamor
added a new API glamor_egl_exchange_buffers() to exchange
two pixmaps' EGL image and fbos and textures without
recreating any of them. But this simple method's requirement
is that there are two pixmaps. A exceptional case is:
If we are using triple buffer when do page flipping, we
will have an extra back_buffer which doesn't have a pixmap
attached to it. Then each time we set that buffer to a
pixmap, we will have to call the create_egl_textured_pixmap
to create the corresponding EGL image and fbo and texture
for it. This is not efficient.
To fix this issue, this commit introduces a new back_pixmap
to intel structure to hold the back buffer and corresponding
glamor resources. Then we will just need to do the light
weight buffer exchanging at both DDX and glamor layer.
As the new back pixmap is similar to the screen pixmap
and need to be handled carefully when close screen. As the
glamor data structure is a per screen data, and will be
released at its close screen method. The glamor's close
screen method must cleanup the screen pixmap and back
pixmap's glamor resources. screen pixmap is easy to get,
but there is no good way to store the back pixmap.
So the glamor add a new API glamor_egl_create_textured_screen_ext
function to pass the back pixmap's pointer to glamor layer.
This commit make us depend on glamor commit: 4e58c4f.
And we increased the required glamor version from 0.3.0 to 0.3.1
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The operations when setting dpms on should be in the order opposite
of what's done when setting dpms off.
This is because of potentially conflicting effects:
~ drmModeConnectoSetProperty() enables/disables the backlight driver.
Some backlight drivers such as intel_backlight set the backlight to 0
when disabled and to max when enabled.
~ intel_output_dpms_backlight() saves the backlight value when turning
DPMS off and restores it when turning DPMS on.
Here's the current order of operations:
xset dpms force off (backlight is nonzero)
drmModeConnectoSetProperty(DPMSModeOff)
kernel: disable backlight, backlight=0
intel_output_dpms_backlight(DPMSModeOff)
save backlight value (0) <-- it has been set to 0 by kernel
set backlight to 0
xset dpms force on
drmModeConnectoSetProperty(DPMSModeOn)
kernel: enable backlight, backlight=max
intel_output_dpms_backlight(DPMSModeOn)
set backlight to saved value (0)
The correct way to do this would be to reverse the operations during
xset dpms force off:
intel_output_dpms_backlight(DPMSModeOff)
save backlight value (nonzero)
set backlight to 0
drmModeConnectoSetProperty(DPMSModeOff)
kernel: enable backlight, backlight=0
This restores the saved nonzero backlight value during the force on.
Signed-off-by: Simon Que <sque@chromium.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Added one configuration option --enable-glamor to control
whether use glamor. Added one new file intel_glamor.c to
wrap glamor egl API for intel driver's usage.
This commit doesn't really change the driver's control path.
It just adds necessary files for glamor and change some
configuration.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is causing a hard hang with 2.6.39+, we don't know why so play safe
and disable for the time being.
References: https://bugs.freedesktop.org/show_bug.cgi?id=38012
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By popular demand.
Triple-buffering trade-offs output latency versus jitter. By having a
pre-rendered frame ready to swap in following a pageflip, we avoid the
scenario where the latency between receiving the flip complete signal
from the kernel, waking up the vsynced application, it render the new
frame and then for the server to process the swap request is greater
than the frame interval, causing us to miss the vblank. The result is
that application can become frame-locked to 30fps. Instead, we report to
the application that the first frame swap is immediately completed,
supply a new back buffer (or else the rendering would be blocked on
waiting for the front-buffer to be swapped away from the scanout) and
let them proceed to render the second frame. The second frame is added
to the swap queue, and the client throttled to vrefresh. (If the client
missed the vblank, the swap queue is empty and the client is immediately
woken again, whilst the pageflip is pending.)
Note, for practical reasons this only applies to page-flipping, for
example, calls to glXSwapBuffer() on fullscreen applications.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As fullscreen swaps were going via a different path to the swapping of
ordinary windows, we were no longer honouring the xorg.conf option to
disable swapbuffer waiting.
This changes the code to only use pageflipping if the Option
"SwapbuffersWait" is set to "TRUE" (default).
Jesse's comment was that this should be superseded by actually
supporting asynchronous page flips. As we are missing kernel and dix level
support for that, in the meantime honour the config option.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Rather than just creating and submitting a batch that simply contains a
flush in order to periodically ensure that rendering reaches the
scanout, we can simply ask the kernel whether the scanout is busy. The
kernel will then submit a flush on our behalf if it is dirty, which
takes advantage of the kernel's dirty state tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A pending swap or flip holds references to drawables and clients which
become invalid when destroyed. Add suitable resources to the database
to track those lifetimes and clean up the pending data structure then.
Later, when the pending swap or flip occurs, handle a missing drawable
by just discarding the flip or swap. Handle a missing client by not
sending an event or reply.
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of using void * for all of the flip_info and swap_info
pointers, just make the underlying structure a public data type and
use that.
Signed-off-by: Keith Packard <keithp@keithp.com>
When a drawable is page-flipped on multiple crtc's (fullscreen
drawable on mirror-mode or multi-head x-screen), only one pageflip
event is finally delivered, after the last participating crtc signals
flip completion, this to avoid visual corruption.
Old code returned vblank count and timestamps of flip completion
of this last crtc, instead of the values of the "master crtc", the
one that was used for initially scheduling/triggering the pagflip
via vblank events. (master = I830DRI2DrawablePipe(drawable))
This patch makes sure that the pageflip completion values of the
"master" crtc are returned, otherwise client applications will
get confused by the random (msc, ust) values returned by whichever
crtc was the last to complete its flip. Without this, the returned
values change randomly and jump forward and backward in time and
count.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel always turns monitors on when doing mode setting, and so no
further DPMS action is required. Note this in the mode setting code by
marking the updated DPMS mode and restoring any saved backlight level.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
A perennial problem we have is the accursed WAIT_FOR_EVENT hangs, which
occur when we switch the framebuffer before the WAIT_FOR_EVENT completes
and upsets the GPU.
We have tried more subtle approaches to detected these and fix them up in
the kernel, to no avail. What we need to do is to delay the framebuffer
flip until the WAIT completes, which is quite tricky in the kernel
without new ioctls and round-trips. Instead, apply the big hammer from
userspace and synchronise all rendering before changing the framebuffer.
I expect this not to cause noticeable latency on switching modes (far
less than the actual modeswitch) and should stop these hangs once and
for all.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31401 (...)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Mark Kettenis
Mickaël THOMAS
Paulo Zanoni
Сковорода Никита Андреевич
Dave Airlie
Tom Hughes
Dave Airlie
Eugeni Dodonov
Zhigang Gong
Simon Que
Keith Packard
Mario Kleiner