The new platform bus code and the old PCI bus code overlap. Platform bus
can handle any type of device, including PCI devices, whereas the PCI code
can only handle PCI devices. Some drivers only support the old style
PCI-probe methods, but the primary device detection code is server based,
not driver based; so we might end up with a primary device which only has
a PCI bus-capable driver, but was detected as primary by the platform
code, or the other way around.
(The above paragraph was shamelessly stolen from Hans de Goede, and
customized.)
The latter case applies to QEMU's virtio-gpu-pci device: it is detected as
a BUS_PCI primary device, but we actually probe it first (with the
modesetting driver) through xf86platformProbeDev(). The
xf86IsPrimaryPlatform() function doesn't recognize the device as primary
(it bails out as soon as it sees BUS_PCI); instead, we add the device as a
secondary graphics card under "autoAddGPU". In turn, the success of this
automatic probing-as-GPU prevents xf86CallDriverProbe() from proceeding to
the PCI probing.
The result is that the server exits with no primary devices detected.
Commit cf66471353 ("xfree86: use udev to provide device enumeration for
kms devices (v10)") added "cross-bus" matching to xf86IsPrimaryPci(). Port
that now to xf86IsPrimaryPlatform(), so that we can probe virtio-gpu-pci
as a primary card in platform bus code.
Cc: Adam Jackson <ajax@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Cc: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-By: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
At startup the server wasn't adding devices, but nothing
was blocking hotplug devices by the look of it.
bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91388
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
xf86platformProbeDev creates GPU screens for any platform devices that were not
matched by a GDev in the loop above, but only if there was at least one device.
This means that it's impossible to configure a device as a GPU screen if there
is only one platform device that matches that driver.
Instead, create a GPU screen (if possible) for any platform device that was not
claimed by the GDev loop.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
If a PCI entity is found, xf86_check_platform_slot performs a device ID check
against the xf86_platform_device passed in. However, it just returns
immediately without checking the rest of the entities first. This leads to this
situation happening:
1. The nvidia driver creates an entity 0 with bus.type == BUS_PCI
2. The intel driver creates entity 1 for its platform device, opening
/dev/dri/card0
3. xf86platformProbeDev calls probeSingleDevice on the Intel platform device,
which calls doPlatformProbe, which calls xf86_check_platform_slot.
4. xf86_check_platform_slot compares the Intel platform device against the
NVIDIA PCI entity. Since they don't have the same device ID, it returns
TRUE.
5. doPlatformProbe calls xf86ClaimPlatformSlot, which creates a duplicate entity
for the Intel one.
Fix this by only returning FALSE if the PCI ID matches, and continuing the loop
otherwise. In the scenario above, this allows it to continue on to find the
Intel platform device that matches the second entity.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
On platforms that don't support PCI or have no GPU attached to the PCI
bus, there can still be a primary device on a non-PCI bus.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When neither of the various bus implementations was able to find a
primary bus and device, fallback to using the platform bus as primary
bus and the first platform device as primary device.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When systemd isn't being used, systemd_logind_release_fd is defined
as an empty macro, leaving the arguments unused. Fix the compiler
warnings by simply removing the local variables and referencing the
structure within the macro call.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
OdevAttributes are a fixed set of values with known types; instead of
storing them in a linked list and requiring accessor/settor functions,
replace the list header, struct OdevAttributes, with a struct that
directly contains the values. This provides for compile-time
typechecking of the values, eliminates a significant amount of code
and generally simplifies using this datatype.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Use the OutputClass configuration to determine what drivers to autoload
for a given device.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-By: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Most of the driver enumeration functions take an array and a maximum
number of entries that they are allowed to fill in. Upon success, they
return the number of entries filled in. This allows them to be easily
used to consecutively.
One exception is the xf86MatchDriverFromFiles() function, which doesn't
return a value, so callers have to manually search the array for the
first empty entry.
This commit modifies the xf86MatchDriverFromFiles() to behave the same
way as others, which makes it easier to deal with.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-By: Aaron Plattner <aplattner@nvidia.com>
Tested-by: Rob Clark <robdclark@gmail.com> (on arm / platform device)
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We can only request one fd per device from systemd-logind. If a fd is re-used
by the same device, releasing the fd from one device doesn't mean we can close
it. The systemd code knows when it's really released, so let it close the fd.
Test case: xorg.conf section for an input device with hotplugging enabled.
evdev detects the duplicate and closes the hotplugged device, which closes the
fd. The other instance of evdev thinks the fd is still valid so now you're
playing a double lottery. First, which client(s) will get the evdev fd?
Second, which requests will be picked up by evdev and which ones will be
picked up by the client? You'll never know, but the fun is in finding out.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This makes how we handle video drivers identical to what we do for input
drivers, and this should make live easier for old non kms drivers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
And use it from xf86platformAddDevice too, instead of directly calling
drvp->platformProbe.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This commits add the bulk of the systemd-logind integration code, but does
not hook it up yet other then calling its init and fini functions, which
don't do that much.
Note the configure bits check for udev since systemd-logind use will only be
supported in combination with udev. Besides that it only checks for dbus
since all communication with systemd-logind is happening over dbus, so
no further libs are needed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
With systemd-logind support, the xserver, rather than the drivers will be
responsible for opening/closing the fd for drm nodes.
This commit adds a fd member to OdevAttributes to store the fd to pass it
along to the driver.
systemd-logind tracks devices by their chardev major + minor numbers, so
also add OdevAttributes to store the major and minor.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The OdevAttributes struct should just be a head of the attributes list, and
not contain various unrelated flags. Instead add a flags field to
struct xf86_platform_device and use that.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Add a couple of new functions for dealing with storing integer values into
OdevAttributes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a config_odev_get_attribute helper, and replace the diy looping over all
the attributes done in various places with calls to this helper.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Send RRResourceChangeNotify event when provider, output or crtc was created or
destroyed. I.e. when the list of resources returned by RRGetScreenResources and
RRGetProviders changes.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
I didn't think we needed this before, but after doing some more
work with reverse optimus it seems like it should be called.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When we disconnect an output/offload slave set the changed bits,
so a later TellChanged can do something.
Then when we remove a GPU slave device, sent change notification
to the protocol screen.
This allows hot unplugged USB devices to disappear in clients.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't want to hotplug output devices while we are VT switched,
as we get races between multiple X servers on the device open, and
drm device master status. This just queues device opens until we return
from VT switch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Due to another bug, the modesetting/udl driver would fail to init properly
on hotplug, when it did the code didn't clean up properly, and on removing
the device the server could crash.
Found in F18 testing.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
For non-PCI video devices, such as those found on many ARM embedded
systems, the X server currently requires the BusID option to specify the
full path to the DRM device's sysfs node in order to properly match it
against the probed platform devices.
In order to allow X to start up properly if either the BusID option was
omitted or no configuration is present at all, the first video device is
used by default.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If we are not seat 0 the following apply:
don't probe any bus other than platform
don't probe any drivers other than platform
assume the first platform device we match on the bus is the primary GPU.
This just adds checks in the correct places to ensure this, and
with this X can now start on a secondary seat for an output device.
v2: fix Seat0 macros
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This solves a race if we are trying to dynamically power off
secondary GPUs. Its not the greatest fix ever but it probably
as good as we can do for now.
The GPU probing causes the devices to be powered up, then when
we scan the PCI bus we get the correct information from the kernel,
rather than a bunch of 0xff due to the device being powered off.
drop gratuitous '&'.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds the initial provider object and provider property
support to the randr dix code.
v2: destroy provider in screen close
v2.1: fix whitespace
v3: update for latest rev of protocol + renumber after 1.4 tearout.
v4: fix logic issue, thanks Samsagax on irc
v5: keithp's review: fix current_role, fix copyrights, fix master
reporting crtc/outputs.
v6: port to new randr interface, drop all set role bits for now
v7: drop devPrivate in provider, not needed, add BadMatch returns
for NULL SetProviderOffloadSink and SetProviderOutputSource, drop
the old typedef.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This option is to stop the X server adding non-primary devices as
gpu screens.
v2: fix per Keith's suggestion.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This provides add/remove support for platform devices at xfree86 ddx level.
v2: cleanup properly if no driver found.
v3: load the modesetting driver before checking driver list.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On Linux in order for future hotplug work, we are required to interface
to udev to detect device creation/removal. In order to try and get
some earlier testing on this, this patch adds the ability to use
udev for device enumeration on Linux.
At startup the list of drm/kms devices is probed and this info is
used to load drivers.
A new driver probing method is introduced that passes the udev
device info to the driver for probing.
The probing integrates with the pci probing code and will fallback
to the pci probe and old school probe functions in turn.
The flags parameter to the probe function will be used later
to provide hotplug and gpu screen flags for the driver to behave
in a different way.
This patch changes the driver ABI, all drivers should at least
be set with a NULL udev probe function after this commit.
v2: rename to platform bus, now with 100% less udev specific,
this version passes config_odev_attribs around which are an array
of id/string pairs, then the udev code can attach the set of attribs
it understands, the OS specific code can attach its attrib, and then
the core/drivers can lookup the required attribs.
also add MATCH_PCI_DEVICES macro.
This version is mainly to address concerns raised by ajax.
v3: Address comments from Peter.
fix whitespace that snuck in.
rework to use a linked list with some core functions that
xf86 wraps.
v4: add free list, fix struct whitespace.
ajax this address most of your issues?
v5: drop probe ifdef, fix logic issue
v6: some overhaul after more testing.
Implement primaryBus for platform devices.
document hotplug.h dev attribs - drop sysname attrib
fix build with udev kms disabled
make probing work like the PCI probe code,
match against bus id if one exists, or primary device.
RFC: add new bus id support "PLAT:syspath". we probably
want to match on this a bit different, or use a different
property maybe. I was mainly wanting this for use with
specifying usb devices in xorg.conf directly, but PLAT:path
could also work I suppose.
v6.1: add missing noop platform function
v7: fix two interactions with pci probing and slot claiming, prevents
pci and platform trying to load two drivers for same slot.
v8: test with zaphod mode on -ati driver, fixup resulting issue
clean up common probe code into another function, change busid
matching to allow dropping end of strings.
v9: fix platform probing logic so it actually works.
v9.1: fix pdev init to NULL properly.
v10: address most of Keith's concerns.
v4 was thanks to Reviewed-by: Adam Jackson <ajax@redhat.com>
v5 was Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
