The idea here is that the driver might have once been old enough to not
have the driverFunc slot in DriverRec, with the module ABI not having
changed when it was added. That was ages ago, and drivers always declare
themselves with DriverRec not DriverRec1, so uninitialized slots will
simply be zero.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Everybody using this functionality specifies a major version, which
makes sense. If you don't care about a minor version, that's equivalent
to saying you require minor >= 0, so just say so; likewise patch level.
Likewise ABI class is always specified.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The enum has been unused since at least the removal of elfloader.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This looks like more, but only if you don't compare it to the number
pulled in by misc.h.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This API is dumb. uname(3) exists, feel free to use it, but ideally
write to the interface not to the OS. There are a couple of drivers
using this API, they could all reasonably just not.
This also removes the OS name from the loader subdirectory path search.
Having /usr/lib/xorg shared across OSes is a non-goal here.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Now that users can set the path only via LoaderSetPath(), we can simplify
things.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Afaics the argument hasn't been part of the API since the documentation
has been converted to xml with commit fc6ebe1e1d "Convert LinuxDoc
documents to DocBook/XML"
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Similar to its little brother - LoadSubModule. Currently all call sites
provide NULL anyway ;-)
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The "copying selected object files" message appears as some source
files have the same name, and some objects are included twice.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
Detailed mode reports 108 mm x 68 mm which is for smaller display.
Maximum image size reports 15 cm x 10 cm which aligns with its physical
size, use this size instead.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Allow OutputClass config snippets to modify the module-path.
Note that any specified ModulePaths will be pre-pended to the normal
ModulePath. The idea behind this is that any output hardware specific
modules should have preference over the normal modules.
One use-case for this is the nvidia binary driver, this allows a
config snippet like this:
Section "OutputClass"
MatchDriver "nvidia"
Modulepath "/usr/lib64/nvidia/modules"
EndSection
To get the nvidia glx specific glx module loaded, but only when the
nvidia kernel driver is loaded.
Together with the glvnd work done recently, this allows the nouveau
+ mesa and nvidia-binary userspace stacks to co-exist on the same
system without any ldconfig / xorg.conf tweaking and the xserver will
automatically do the right thing depending on which kernel driver
(nouveau or nvidia) is loaded.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Allow using:
Option "PrimaryGPU" "yes"
In an OutputClass section to override the default primary GPU device
selection which selects the GPU used as output by the firmware.
If multiple output devices match an OutputClass section with
the PrimaryGPU option set, the first one enumerated becomes the
primary GPU.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a preparation patch for allowing an OutputClass section to
override the default primary GPU device selection.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for setting options in OutputClass Sections and having these
applied to any matching output devices.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Make OutputClassMatches directly take a xf86_platform_device as argument,
rather then an index into xf86_platform_devices. This makes things
easier for callers which already have a xf86_platform_device pointer.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
xf86MatchDevice returns a dynamically allocated list of GDevPtr-s,
free this when we're done with it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
In InitOutput, if xf86HandleConfigFile returns CONFIG_NOFILE
(which it does if no config file or directory is present), the
autoconfig flag is set, causing xf86AutoConfig to be called
later on.
xf86AutoConfig calls xf86OutputClassDriverList via the
call tree:
xf86AutoConfig =>
listPossibleVideoDrivers =>
xf86PlatformMatchDriver =>
xf86OutputClassDriverList
and xf86OutputClassDriverList attempts to traverse a linked list
that is a member of the XF86ConfigRec struct pointed to by the
global xf86configptr, which is NULL at this point because the
XF86ConfigRec struct is only allocated (by xf86readConfigFile)
AFTER the config file and directory have been successfully
opened; the CONFIG_NOFILE return from xf86HandleConfigFile
occurs BEFORE the call to xf86readConfigFile which allocates
the XF86ConfigRec struct.
Rx: In read.c (for symmetry with xf86freeConfig, which already
appears in this file), add a new function xf86allocateConfig
which tests the value of xf86configptr and, if it's NULL,
allocates the XF86ConfigRec struct and deposits the pointer
in xf86configptr. In xf86Parser.h, add a prototype for the
new xf86allocateConfig function.
Back in read.c, #include "xf86Config.h". In xf86readConfigFile,
change the open-code call to calloc to a call to the new
xf86allocateConfig function.
In xf86AutoConfig.c, add a call to the new xf86allocateConfig function
to the beginning of xf86AutoConfig to make sure the XF86ConfigRec struct
is allocated.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ben Crocker <bcrocker@redhat.com>
If we did not find any non GPU Screens, try again ignoring the notion
of any video devices being the primary device. This fixes Xorg exiting
with a "no screens found" error when using virtio-vga in a
virtual-machine and when using a device driven by simpledrm.
This is a somewhat ugly solution, but it is the best I can come up with
without major surgery to the bus and probe code.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is primarily a preparation patch for fixing the xserver exiting with
a "no screens found" error even though there are supported video cards,
due to the server not recognizing any card as the primary card.
This also fixes the (mostly theoretical) case of a platformBus capable
driver adding a device as GPUscreen before a driver which only supports
the old PCI probe method gets a chance to claim it as a normal screen.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
If foundScreen is TRUE, then all the code below the removed if
will not execute until we reach the return foundScreen; at the
end, so this entire if block is redundant.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option
"SWCursor" is specified, sPriv == NULL. In this case we should assume that HW
cursors are not supported.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Commit c7e8d4a6ee had already unifdef
MODESETTING_OUTPUT_SLAVE_SUPPORT but commit
9257b1252d didn't notice that.
Signed-off-by: Nikhil Mahale <nmahale@nvidia.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Prior to this commit the Xorg.wrap code to detect if root rights are
necessary checked for DRM_IOCTL_MODE_GETRESOURCES succeeding *and*
reporting more then 0 output connectors.
DRM_IOCTL_MODE_GETRESOURCES succeeding alone is enough to differentiate
between old drm only cards (which need ums and thus root) and kms capable
cards.
Some hybrid gfx laptops have 0 output connectors on one of their 2 GPUs,
resulting in Xorg needlessly running as root. This commits removes the
res.count_connectors > 0 check, fixing this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a missing ifdef needed for --disable-glamor.
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Special case for the systemd-logind case in xfree86: when we're vt-switched
away and a device is plugged in, we get a paused fd from logind. Since we
can't probe the device or do anything with it, we store that device in the
xfree86 and handle it later when we vt-switch back. The device is not added to
inputInfo.devices until that time.
When the device is removed while still vt-switched away, the the config system
never notifies the DDX. It only runs through inputInfo.devices and our device
was never added to that.
When a device is plugged in, removed, and plugged in again while vt-switched
away, we have two entries in the xfree86-specific list that refer to the same
device node, both pending for addition later. On VT switch back, the first one
(the already removed one) will be added successfully, the second one (the
still plugged-in one) fails. Since the fd is correct, the device works until
it is removed again. The removed devices' config_info (i.e. the syspath)
doesn't match the actual device we addded tough (the input number increases
with each plug), it doesn't get removed, the fd remains open and we lose track
of the fd count. Plugging the device in again leads to a dead device.
Fix this by adding a call to notify the DDX to purge any remainders of devices
with the given config_info, that's the only identifiable bit we have at this
point.
https://bugs.freedesktop.org/show_bug.cgi?id=97928
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes but it makes it easier to remove elements from the
middle of the list (future patch).
We don't have an init call into this file, so the list is manually
initialized.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
They're identically laid-out structs but let's use the right type to search
for our desired value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Prevents the HW cursor from intermittently jumping around when the
cursor image is changed while the cursor is being moved. This is hardly
noticeable in normal operation but can be quite confusing when stepping
through these codepaths in a debugger.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens.
Fixes incorrect HW cursor position on PRIME slave screens.
Also hoist the hotspot translation out from xf86ScreenSet/MoveCursor to
xf86Set/MoveCursor, since the hotspot position is a property of the
cursor, not the screen.
v2:
* Squash patches 1 & 2 of the v1 series, since it's basically the same
problem
* Use the master screen's xf86CursorScreenRec::HotX/Y instead of
CursorRec::bits->x/yhot, since CursorRec::bits can be NULL (Hans de
Goede)
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
As of last commit all the places in our configure.ac require version
2.3.1 (released back in 2007) or later. With the latter introducing the
1.3.0 version, as returned by drmGetLibVersion.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Presently the option guards both direct and accelerated indirect GLX. As
such when one toggles it off they end up without any acceleration.
Remove the option all together until we have the time to split/rework
things.
Cc: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The option is misleading and using it leads to disabling both direct and
accelerated indirect GLX. In such cases the xserver GLX attempts to
match DRISW (IGLX) configs with the DRI2/3 ones (direct GLX) leading to
all sorts of fun experience.
Remove the option until we get a clear split and control over direct vs
indirect GLX.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This change effectively reverts commit 074cf58. We were falling back from
drmModeSetCursor2() to drmModeSetCursor() whenever the first failed. This
fall-back only makes sense on pre-mid-2013 kernels which implemented the
cursor_set hook but not cursor_set2, and in this case the call to
drmModeSetCursor2() will always return -EINVAL. Specifically, a return
value of -ENXIO usually means that neither are supported.
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
[hdegoede@redhat.com: initialize ret to -EINVAL]
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We get multiple udev events for actions like docking a laptop into its
station or plugging a monitor to the station. By consuming as much
events as we can, we reduce the number of output re-evalutions.
I.e. having a Lenovo X250 in a ThinkPad Ultra Dock and plugging a
monitor to the station generates 5 udev events. Or having 2 monitors
attached to the station and docking the laptop generates 7 events.
It depends on the timing how many events can consumed at once.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
[hdegoede@redhat.com: Keep goto out so that we always call RRGetInfo()]
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This fix is for the following xorg.conf can work:
Section "ServerFlags"
Option "AutoAddGPU" "off"
EndSection
Section "Device"
Identifier "Amd"
Driver "ati"
BusID "PCI:1:0:0"
EndSection
Section "Device"
Identifier "Intel"
Driver "modesetting"
BusID "pci:0:2:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Intel"
GPUDevice "Amd"
EndSection
Without AutoAddGPU off, modesetting DDX will also be loaded
for GPUDevice.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93675
Signed-off-by: Kyle Guinn <elyk03@gmail.com>
[hdegoede@redhat.com: Simplify by adding 2 if conds together with &&]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
A couple of memory leaks fixes and avoiding bit shifting on an
unitialized value.
[hdegoede@redhat.com: Split out some non free fixes in separate patches]
[hdegoede@redhat.com: Don't touch ancient (and weird) os/rpcauth.c code]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Commit b4e46c0444 ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
code. Leaving pScrn->ChangeGamma NULL in most cases.
This triggers the BadImplementation error in xf86ChangeGamma() :
if (pScrn->ChangeGamma)
return (*pScrn->ChangeGamma) (pScrn, gamma);
return BadImplementation;
Which causes X-apps using XF86VidModeSetGamma to crash with a
X protocol error.
This commit fixes this by re-introducing the xf86RandR12ChangeGamma
helper removed by the commit and adjusting it to work with the new
combined palette / gamma code.
Fixes: b4e46c0444 ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Adam Jackson
Emil Velikov
Mihail Konev
Qiang Yu
Kai-Heng Feng
Hans De Goede
Ben Crocker
Timo Aaltonen
Keith Packard
Alex Goins
Jon Turney
Nikhil Mahale
Michel Dänzer
Peter Hutterer
Michael Thayer
Daniel Martin
Laszlo Ersek
Kyle Guinn
David CARLIER