If some outputs go away we race with this call and apps
get X errors and fall over. Do what SNA does and don't
bother trying.
Signed-off-by: Dave Airlie <airlied@redhat.com>
While fixing up UXA for MST I eventually fell over this bug.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[ickle: replace constant with macro to track pipe-dependent code]
fbpict.h has been an installed header since 2008, shortly after uxa
landed. This fixes compiler warnings when other headers happen to
include fbpict.h.
Based on the patch by Kenneth Graunke,
"Several places (such as intel_cache_expire) call intel_emit_batch_flush,
so it needs to work on Broadwell. Sometimes the batch is empty, in
which case current_batch may not yet be BLT_RING.
The PIPE_CONTROL code has not been ported to work on Broadwell, so
trying to do a render ring flush will hang the GPU. It also doesn't
make any sense to do a render ring flush, given that we never use the
render ring for UXA on Broadwell."
Cc: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Based on the patch by Hans de Goede, this removes the handling of
drmOpen() and DRM_MASTER from within uxa and instead uses the common
routines. This reduces the duplicate code from within uxa, and enables
new features such as server managed fds.
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This supports solid, copy, put_image, and get_image acceleration via the
BLT engine. RENDER acceleration (composite) and Xv would be piles of work,
which is not worth doing since SNA exists, and Glamor is coming.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Our fallback path for finding the backlight interface uses a hardcoded
table of known backlight controllers in proirity order. Rather than
maintain this table twice in the midst of the KMS logic, push it to the
new set of common backlight routines.
This incorporates bugfixes from SNA to handle unknown backlights, but
usable, gracefully.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once the xserver stops running as root on kms capabable systems, we will need
some other way to access the backlight.
The approach taken in this patch moves most of the heavy lifting to a
helper that runs with root privileges and pipes our requested brightness
into the sysfs backlight interface. Where required, we use pkexec to
launch the helper with the elevated privilege.
v2: Amalgamate much more of the duplicate code.
Keep the daemon and pipe alive for the lifetime of the backlight interface.
Provide an alternative for systems without PolicyKit.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> [v1]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before attaching properties to any connector, check that we can indeed
control the backlight through the sysfs interface by doing an access
check. If the xserver is started without root privileges, we cannot
write through /sys/class/backlight and so should take care not to
advertise that we can.
Reported-by: Hans de Geode <hdegeode@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 4497212307.
Unfortunately, this simple fix does not work for UXA as DPMS is used by
the xserver to turn off CRTCs and outputs. Since UXA does not implement
CRTC DPMS, this commit causes us to fail to turn off outputs.
The kernel has been fixed up in the meantime and that commit has been
recommended to be backported to all stable kernels:
commit c9976dcf55c8aaa7037427b239f15e5acfc01a3a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Sep 29 19:15:07 2013 +0100
drm/i915: Only apply DPMS to the encoder if enabled
so it should be safe for UXA to rely on its old behaviour.
Bugzilla: https://code.google.com/p/chromium/issues/detail?id=341135
References: https://bugs.freedesktop.org/show_bug.cgi?id=68030
Suggested-by: Dominik Behr <dbehr@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In addition to the UXA texture paths (which in theory support VSync) and
direct overlay support, create a textured video paths that utilize the
glamor acceleration code.
Requested-by: Fabio Pedretti <fabio.ped@libero.it>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74311
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Inspired by (ok, copied from):
xf86-video-ati commit f2a0a5cf6c5a21e2a02280e110a4eb8e6609dace
Author: Michel Dänzer <michel.daenzer@amd.com>
Date: Wed Jan 22 11:04:42 2014 +0900
Don't require the glamoregl module to be pre-loaded with xserver >= 1.15
The issues with loading it on demand have been fixed in xserver 1.15.
Inspired by Jérôme Glisse on IRC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since 2010, DRI2 supports multiple driver names. That was added to ease
selection of appropriate driver by libvdpau. As for today, intel driver
support only DRI2DriverDRI (== 0), but not DRI2DriverVDPAU (== 1).
Although there is no any hardware-specific VDPAU driver for intel video
adapters at the moment, it would be easier to use generic drivers like
libvdpau-va-gl by creating symlink named libvdpau_i965.so.1. That way
appropriate driver will be selected in run time automatically:
libvdpau_i965.so.1 on i965 equipped machines, and libvdpau_nvidia.so.1
on nvidia equipped ones.
[ickle: Whilst I think this is a workaround for a brainfart in libvdpau
that it defaults to libvdpau_nvidia.so rather than first to
libdvpau_${DRI2DriverDRI} and then to a hardcoded libvdpau_backend.so,
I have no better solution, and this does seem in accordance with the
spec.]
Signed-off-by: Rinat <ibragimovrinat@mail.ru>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73507
As we assume that Suspend, Standby alias to Off and disable the crtc
when switching to any mode other than On, we need to also perform the
backlight updates for Suspend,Standby prior to passing the DPMS value
onto the kernel.
Suggested-by: Alexander Monakov <amonakov@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Backport commit e76b08cad2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Oct 15 12:46:09 2013 +0100
sna: Disable updating properties upon reading their values
in order to prevent random screen blanking upon return from DPMS.
Reported-by: Alexander Monakov <amonakov@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73181
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the code current assumes that pixmaps are located at screen origin
(0,0), it assumes that they are all on the first CRTC. However, since
they are offscreen, this leads to such complications as attempting to
emit vsync swapbuffers, and even worse attempting to swap a GLXPixmap
onto the scanout following a DRI2SwapBuffers.
Reported-by: Alexander Monakov <amonakov@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73282
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xf86AddGeneralHandler returns an opaque pointer, not a function pointer.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid using @var@ since this could not be easily overwritten through
'make var=xxx' option which is normally available.
For Makefile.am users should avoid using @var@.
Signed-off-by: Zdenek Kabelac <zkabelac@redhat.com>
With the advent of DRI3 (and previously with Prime and Glamor) we have
external clients who rely on the pixmap<->bo mapping being invariant.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For a large screen, we have to create a temporary surface for rendering
the textured video. If this pixmap creation fails we may be left with a
system memory only pixmap leading to a segfault.
Reported-by: Bas Wijnen <wijnen@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One of UXA's invarients is that the ScreenPixmap is complete (i.e. has
an intel_pixmap private with a bo attached). If we fail to create that
private during CreateScreenResources we will die very soon afterwards,
so just report the failure and shutdown gracefully.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After some probing mechanisms, we may end up with a valid device without
knowing its PCI address a priori. Having a valid device, we can just
query it for the correct device id, and can safely abort any path that
requires PCI information that we don't have. (Those paths are not valid
under such hosting anyway - if it may be required, we could reconstruct
the address.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The operation is in theory redundant, and in the case of Haswell where
we have multiple outputs aliasing to the same encoder, actually harmful.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Stefan Dirsch <sndirsch@suse.de>
We can shave a few instructions off the routine by incrementally
performing the "is-empty" check as soon as we compute the intersection
in each dimension.
xf86InterpretEDID() doesn't copy the EDID raw data in xf86MonPtr but
just stores the given pointer. The DDX driver needs to make sure that
data stays valid.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Dave Airlie
Dave Airlie
Chris Wilson
Eric Anholt
Kenneth Graunke
Rinat
Zdenek Kabelac
Raul Fernandes
Damien Lespiau
Egbert Eich