Beware the barbarians at the gate, who invade and steal your ScrnInfoPtr
and its Entity from underneath you. In some configurations, we lose
access to the struct intel_device stored on the Entity after
initialisation, causing havoc. Workaround this by storing the
intel_device that we open in our driverPrivate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We only automount debugfs for Linux, but sys/mount.h on BSD has unmet
dependencies breaking the build.
Reported-by: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Other platforms are not going to have the same debug infrastructure, nor
even the same mount(2).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we require debugging information from debugfs and we cannot find it,
silently mount it and dump the information we need.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to claim the DRM device as master, dump /debugfs/.../clients
so that we can check to see who failed to drop master for us.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As root, X gets away with many things, including submitting commands to
the DRM device whilst it is no longer authorised (i.e. when it has
relinquished master to another client across a VT switch). In the
non-root future, if we attempt to use the device whilst unauthorized the
rendering will be lost and we will mark the device as unusable. So flush
our render queue to the device around a VT switch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the path we want to open for the KMS device is not yet available,
wait a short while and try again.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80397
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The call to GETPARAM requires either a rendernode or authorisation.
Therefore we can only assert that the fd is a valid i915 handle after
authorise() and not before.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
SET_MASTER and DROP_MASTER are only available to the root user. If we
are started as an ordinary user, and we are master by virtue of being
the first user of the device, never release our fd or master.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we are given an fd by the Xserver, then it is not our responsibility
to close it during CloseScreen.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Hans de Goede <hdegoede@redhat.com>
Since we already lookup the device path if we do not know it after
opening the fd, we can remove the special case along the legacy PCI
probe path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I hit this corner case when testing a single X server spanning both intel
gfx + an usb display link adapter driven by xf86-video-modesetting.
In this scenario the intel driver gets its platformProbe method called first,
and if it then closes the server managed fd, the xf86-video-modesetting gets
EBADFD errors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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>
If we are not supplied the path, call the libdrm function to search for
the canonical name for our device.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If for some reason we have an fd, but no device path, use the likely
default path (derived from and validated against the major/minor of the
open device fd).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the post-modern world, the platform device nodes are handed to a
non-privileged Xserver by systemd/logind. We can then query the core for
our assigned fd rather than try to open the device for ourselves (which
would fail when trying to obtain DRM_MASTER status). A consequence is
that we then do not directly control DRM_MASTER status and must act as a
delegate of systemd.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
O_NONBLOCK is a status flag not a descriptor flag, so F_GETFL / F_SETFL should
be used to modify it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
intel_device.c: In function 'intel_entity_get_devid':
intel_device.c:82:32: warning: declaration of 'index' shadows a global declaration [-Wshadow]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only fail to open the device based on the PCI address, if and only if we
do not have sufficient platform information to find the correct system
device.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One extreme fallback path through the xf86PlatformProbe results in a
call without any match data. As we have a device by this point, we can
simply do a reverse match.
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>
Check first for a NULL platform device before querying the attributes or
else suffer a segfault during PCI probing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is WIP for passing along a hosted fd. It wasn't meant to be pushed
along with the bug fix this morning.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Under a compositor, we wish to use the pre-authorized fd passed to us by
the host, stashed away in the platform device.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This allows us to pass along more metadata along with the platform
device in future. Currently we pass the device path, but in a hosted
environment we should be passing along the authorized fd from the host.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With lots of updates by Christopher James Halse Rogers as he updated the
XMir API - but now supposedly frozen!
"<RAOF> ickle: I think the xmir api should be pretty much stable now,
barring people coming up with more awesome ways of doing things."
Signed-off-by: Christopher James Halse Rogers <raof@ubuntu.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Render nodes allow clients full access to off-screen rendering and GPU
offload, without assuming any master responsiblities (for device and
display management). As they have a more limited interface, they can be
used in a more permissive manner.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Start adding the infrastructure to disable direct hardware access if X
is being run under a system compositor (aka "hosted").
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently we leak the fd should we open the device node and decide that
is not a GEM/KMS kernel driver. The simplest way to perform the cleanup
upon failure is to move the checking for GEM/KMS into the device open
routine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use drmSetMaster/drmDropMaster instead of calling the ioctls
directly. Fixes compilation on OpenBSD where these ioctls
aren't defined.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Avoid having to search the device tree once again in order to simply
recover the path we used to open the device.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we reacquire master when initialisation the next gen of the server,
to keep the reference counting consistent we need to release our master
reference on CloseScreen.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Merge the device open in the main driver with the probing so that we can
open the path explicitly passed in by the PlatformProbe and keep that fd
around for the main driver and so avoid a later search.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Hans de Goede
Jonathan Gray