I don't think this is useful information to have in the log, and it's
a bunch of autotools and meson logic to produce it.
Signed-off-by: Eric Anholt <eric@anholt.net>
60ec8ead broke the autotools build:
sdksyms.o:(.data+0x58): undefined reference to `InitConnectionLimits'
sdksyms.o:(.data+0x2ec8): undefined reference to `xf86ServerName'
collect2: error: ld returned 1 exit status
Makefile:811: recipe for target 'Xorg' failed
Likewise 3a4d7c79 for InitConnectionLimits.
Signed-off-by: Adam Jackson <ajax@redhat.com>
If it's really this important we should just do it and not complain. We
never do it so it must not matter.
Signed-off-by: Adam Jackson <ajax@redhat.com>
I'm sure printing the address of function pointers in modules you'd
loaded might have made sense back when we rolled our own dlopen, but we
got better.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The old code would not in fact validate the option value, though it
might complain about it in the log. It also didn't let you set some
legal values that the -maxclients command line option would.
Signed-off-by: Adam Jackson <ajax@redhat.com>
DGAShutdown() walks every screen and attempts to reset the mode. That's
maybe a reasonable thing to do, although the explicit loop is certainly
a bad smell.
In ddxGiveUp it's called after we've torn down the vga arbiter - and in
fact most of the rest of screen state - which is... very very bad. The
other place it's called is from the Control-Alt-BackSpace handler, where
we don't even attempt to do vga arb setup, and where in any case we're
going to escape the main loop eventually anyway.
Move all that cleanup work inside DGACloseScreen. This means it happens
earlier in server teardown than previously, but not in a way you're ever
going to be upset about.
Signed-off-by: Adam Jackson <ajax@redhat.com>
This makes us match the featureset of autotools, and also fixes the
non-Linux default value to match.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have pm_noop.c being built most of the time for the
no-OS-PM case, so just switch to always using it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This lets an application open a suitable DRM device and pass the file
descriptor to the mode setting driver through an X server command line
option, '-masterfd'.
There's a companion application, xlease, which creates a DRM master by
leasing an output from another X server. That is available at
git clone git://people.freedesktop.org/~keithp/xlease
v2:
Always print usage, but note that it can't be used if
setuid/gid
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
In commit 9db2af6f75 (xfree86: Remove xf86{Map,Unmap}VidMem) we
somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
function pointer indirection was intended to support dense vs sparse and
sparse support is now gone, we can just make the functions static inline
in compiler.h and avoid all of this.
Bugzilla: https://bugs.gentoo.org/548906
Tested-by: Christopher May-Townsend <chris@maytownsend.co.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
The newline before the protocl version got lost in commit
6cbefc3e0a. Prior to that commit, the
release date printed a newline at the end:
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.12-1-ARCH x86_64
Now, that string gets run together with the version:
X.Org X Server 1.19.99.903 (1.20.0 RC 3)X Protocol Version 11, Revision 0
Build Operating System: Linux
Since the version string printing has a variety of #ifdefs in it, just
add the newline to the begining of the protocol version string.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[... but leave it defined and exported, since we're ABI-frozen - ajax]
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Ben Crocker <bcrocker@redhat.com>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
Tested-by: Ben Crocker <bcrocker@redhat.com>
restore abi
Having different types of code all trying to check for elevated privileges
is a bad idea. This implementation is the most thorough one.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Ben Crocker <bcrocker@redhat.com>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
Tested-by: Ben Crocker <bcrocker@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Implement function added in DRI3 v1.1.
A newest version of libepoxy (>= 1.4.4) is required as earlier
versions use a problematic version of Khronos
EXT_image_dma_buf_import_modifiers spec.
v4: Only send scanout-supported modifiers if flipping is possible
v5: Fix memory corruption in XWayland (uninitialized pointer)
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The big change here is MakeCurrent and context tag tracking. We now
delegate context tags entirely to the vnd layer, and simply store a
pointer to the context state as the tag data. If a context is deleted
while it's current, we allocate a fake ID for the context and move the
context state there, so the tag data still points to a real context. As
a result we can stop trying so hard to detach the client from contexts
at disconnect time and just let resource destruction handle it.
Since vnd handles all the MakeCurrent protocol now, our request handlers
for it can just be return BadImplementation. We also remove a bunch of
LEGAL_NEW_RESOURCE, because now by the time we're called vnd has already
allocated its tracking resource on that XID.
v2: Update to match v2 of the vnd import, and remove more redundant work
like request length checks.
v3: Add/remove the XID map from the vendor private thunk, not the
backend. (Kyle Brenneman)
v4: Fix deletion of ghost contexts (Kyle Brenneman)
Signed-off-by: Adam Jackson <ajax@redhat.com>
DoConfigure() attempts to call the PreInit handler on a device without
checking that the handler exists.
Check that the PreInit handler exists for a device before attempting to
call it.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When the dev2screen is sized to xf86NumDrivers in DoConfigure(),
subsequent code may attempt to write past the end of the array.
Size the dev2screen array to nDevToConfig instead.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Commits b5dffbb and d75ffcd introduce code in xf86platformProbe() that
references a member of xf86configptr. However, when using the
"-configure" option, xf86configptr may not be initialized when
xf86platformProbe() is called.
Avoid referencing a member of xf86configptr if uninitialized.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100405
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
xf86pciBus.c:1464:21: warning: comparison of constant 256 with expression of type 'uint8_t' (aka 'unsigned char') is always true [-Wtautological-constant-out-of-range-compare]
if (pVideo->bus < 256)
The code used to be in xf86FormatPciBusNumber and compared parameter which was int, but since b967bf2a it was inlined now it works with uint8_t.
The only way to get at xf86Info.disableRandR from configuration is
Option "RANDR" "foo" in ServerFlags, which probably nobody is using
seeing as it's not documented. The other way it could be set is if a
screen supports RANDR 1.2, in which case we set it to avoid trying to
use the RANDR 1.1 compat code. If the second screen is not 1.2-aware
then this would mean we don't do RANDR setup on the second screen at
all, which would almost certainly crash the first time you try to do
RANDR operations on the second screen.
Fix that all by deletion, and just check whether the screen already has
RANDR initialized before installing the stub support. If you want to
disable RANDR, use the Extensions section of xorg.conf instead.
v2: Also remove a now entirely pointless log message, telling you to
ignore a line we will no longer print.
v3: Explain the fallback path in InitOutput. (Keith Packard)
v4: Check whether the RANDR private key is initialized before trying to
use it to look up the screen private.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tsk. This broke vesa for me, the rrGetScrPriv in InitOutput will crash
if randr's screen private key hasn't been initialized yet. That seems
dumb, but let's not leave it broken.
This reverts commit c08d7c1cdd.
The only way to get at xf86Info.disableRandR from configuration is
Option "RANDR" "foo" in ServerFlags, which probably nobody is using
seeing as it's not documented. The other way it could be set is if a
screen supports RANDR 1.2, in which case we set it to avoid trying to
use the RANDR 1.1 compat code. If the second screen is not 1.2-aware
then this would mean we don't do RANDR setup on the second screen at
all, which would almost certainly crash the first time you try to do
RANDR operations on the second screen.
Fix that all by deletion, and just check whether the screen already has
RANDR initialized before installing the stub support. If you want to
disable RANDR, use the Extensions section of xorg.conf instead.
v2: Also remove a now entirely pointless log message, telling you to
ignore a line we will no longer print.
v3: Explain the fallback path in InitOutput. (Keith Packard)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Fixes double-free later in xf86XvMCCloseScreen, which would generally
cause fireworks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
This no longer does anything useful.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The only consumer of this is the Linux vm86 backend for int10 (which you
should not use), and there all it serves to do is make signals generated
by the vm86 task non-fatal. In practice this error appears never to
happen, and marching ahead with root privileges after arbitrary code has
raised a signal seems like a poor plan.
Remove the usage in the vm86 code, making this error fatal.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This was added in ~2004 for the sis driver, to detect whether it could
use SSE for memcpy. Charmingly, the code to check whether that feature
exists in the server is:
#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(6,8,99,13,0)
#define SISCHECKOSSSE /* Automatic check OS for SSE; requires SigIll facility */
#endif
Which means it has never worked in any modular server release.
A less gross way to do this is to check for SSE support with getauxval()
or /proc/cpuinfo or similar. Since no driver is using the existing
intercept mechanism, drop it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with
the ARRAY_SIZE macro from dix.h when possible. A semantic patch for
coccinelle has been used first. Additionally, a few macros have been
inlined as they had only one or two users.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
By having it as a custom_target with build_always, every "ninja -C
build" would rebuild Xorg for the new date/time, even if the rest of
Xorg didn't change.
We could build the rest of Xorg into a static lib, and regenerate
date/time when the static lib changes and link that into a final Xorg,
but BUILD_DATE/TIME is such a dubious feature (compared to including a
git sha, which is easy with meson) it doesn't seem worth the build
time cost.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There were two bugs here: The comparison function was not stable when
one or more of the drivers being compared is a fallback, and the last
driver in the list would never be moved.
Signed-off-by: Adam Jackson <ajax@redhat.com>
xf86str.h is parsed into sdksyms unconditionally but the symbol is only
defined when building with PCI support. Move the decl to a header that
sdksyms only parses when building PCI support.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
This symbol is used by some DRI2+ drivers and there's nothing
DRI1-specific about it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
It was attempting to use the <bus>@<domain> format accepted by the BusID
stanza, but the two values were swapped.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
The PCI domain has to be specified like this:
"PCI:<bus>@<domain>:<device>:<function>"
Example before:
(--) PCI:*(0:0:1:0) 1002:130f:1043:85cb [...]
(--) PCI: (0:1:0:0) 1002:6939:1458:229d [...]
after:
(--) PCI:*(0@0:1:0) 1002:130f:1043:85cb [...]
(--) PCI: (1@0:0:0) 1002:6939:1458:229d [...]
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
./hw/xfree86/common/xf86pciBus.c: In function ‘xf86MatchDriverFromFiles’:
../hw/xfree86/common/xf86pciBus.c:1330:52: warning: ‘snprintf’ output may be
truncated before the last format character [-Wformat-truncation=]
snprintf(path_name, sizeof(path_name), "%s/%s", ^~~~~~~
../hw/xfree86/common/xf86pciBus.c:1330:13: note: ‘snprintf’ output between 2
dirent->d_name is 256, so sprintf("%s/%s") into a 256 buffer gives us:
and 257 bytes into a destination of size 256
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
gcc -std=c99 does not define the former, and it's a horrible namespace
confusion anyway.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Implementation of new drivers matching algorithm. New approach
doesn't add duplicate drivers and ease drivers matching phase.
v2: Re-commit the patch reverted in
2388f5e583, with Aaron Plattner's
fix squashed in (by anholt).
Signed-off-by: Karol Kosik <kkosik@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v1)
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Eric Anholt <eric@anholt.net>
This reverts commit 112d0d7d01.
It broke Xorg for Adam, Peter, and myself, by failing hard when a
module load failed.
Signed-off-by: Eric Anholt <eric@anholt.net>
glibc would like to stop declaring major()/minor() macros in
<sys/types.h> because that header gets included absolutely everywhere
and unix device major/minor is perhaps usually not what's expected. Fair
enough. If one includes <sys/sysmacros.h> as well then glibc knows we
meant it and doesn't warn, so do that if it exists.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Implementation of new drivers matching algorithm. New approach
doesn't add duplicate drivers and ease drivers matching phase.
Signed-off-by: Karol Kosik <kkosik@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We mostly use #ifdef throughout the tree, and this lets the generated
config.h files just be #define TOKEN instead of #define TOKEN 1.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Without this, assertion failures can make life hard for users and those
trying to help them.
v2:
* Change commit log wording slightly to "can make life hard", since
apparently e.g. logind can alleviate that somewhat.
* Set default handler for SIGABRT in
hw/xfree86/common/xf86Init.c:InstallSignalHandlers() and
hw/xquartz/quartz.c:QuartzInitOutput() (Eric Anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
parser/scan.c was checking for #ifdef XCONFIGFILE and XCONFIGDIR and
defaulting to "xorg.conf", and "xorg.conf.d", so if you had changed
__XCONFIGFILE__ to anything else, it would have got out of sync.
Settle on the name without gratuitous underscores.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
No driver is using these, as far as I know.
v2: Tripwire the entity hook arguments to xf86Config*Entity, fix
documentation (Eric Anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Most of this is a legacy of the old "extmod" design where you could load
_some_ extensions dynamically but only if the server had been built with
support for them in the first place.
Note that since we now only initialize the DPMS extension if at least
one screen supports it, we no longer need DPMSCapableFlag: if it would
be false, we would never read its value.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Following on from the previous change, this adds a DPMS hook to the
ScreenRec and uses that to infer DPMS support. As a result we can drop
the dpms stub code from Xext.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Rather than setting up a per-screen private, just conditionally
initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
that to determine whether DPMS is supported.
We also move the "turn the screen back on at CloseScreen" logic into the
DPMS extension's (new) reset hook. This would be a behavior change for
the non-xfree86 servers, if any of them had non-stub DPMS support.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
There's really no reason to pretend to support this, apps hate it, all
we're doing is giving people a way to injure themselves. It doesn't work
anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810.
Rip out all the logic for handling 24bpp pixmaps and framebuffers, and
silently ignore the old options that would ask for it.
The cirrus alpine driver has been updated to default to 16bpp, and both
it and the i810 driver can now use the 32->24 conversion code in shadow
if they want. All other drivers support 32bpp. Configurations that
explicitly request 24bpp in order to fit in VRAM will be broken now
though.
v2: Fix command line options to silently ignore 24bpp rather than fail
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This touches everything that ends up in the Xorg binary; the big missing
part is GLX since that's all generated code. Cuts about 14k from the
binary on amd64.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
First, move them to the end of the struct, for marginally better cache
locality for the struct members that actually have meaning; move the
existing slots at the end of the struct up near some others with similar
meanings. Second, only keep four slots each of integer, data pointer,
and function pointer; we've rarely used this escape hatch so this is
still plenty.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Never set by the core, not used in any modern driver.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Just no.
The ddxDesign chunk removes the whole para about xf86FixPciResource,
since it turns out that function doesn't exist at all anymore.
The only drivers that reference this at all are i128 and mga, and even
then only in the non-pciaccess path.
v2:
- Update commentary about i128/mga
- Don't remove the BiosBase keyword from the config parser since that
would turn a no-op into a fatal error (Aaron Plattner)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Seriously not worth the effort of tracking this, especially now that
competent drivers don't have a limit. The sis driver does inspect this
member, but hilariously does so only so it can print the same information
as the core does.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Only mach64 and rendition actually use this feature. Everyone else just
checks it in their ValidMode hook, they can too.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We don't actually need (or intend) to keep this struct the same across
revisions.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Nobody was ever calling this with a non-null argument for subdir list or
pattern list. Having done this, InitSubdirs is only ever called with a
NULL argument, so it's really just a complicated way of duplicating the
default list; we can remove that and just walk the list directly.
The minor error code was only ever used to distinguish among two cases
of LDR_BADUSAGE. Whatever.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Callers only ever use this for a single directory anyway.
While we're at it, also move xf86DriverListFromCompile near its only
user in the X -configure code (and inline it out of existence), and
remove LoaderFreeDirList as it's unused (since X -configure is just
going to exit anyway, none of that code cares about cleanup).
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
There's no reason a driver should ever care about this.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
indent(1) gets confused by function-like macros with no trailing
semicolon, which is fair enough really.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
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>
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>
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>
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>
Ross Burton
Eric Anholt
Adam Jackson
Julien Isorce
Keith Packard
Matt Turner
Aaron Plattner
Nicolai Hähnle
Louis-Francis Ratté-Boulianne
Laurent Carlier
Jeff Smith
Michal Srb
Michel Dänzer
Martin Wilck
Daniel Martin
Nathan Kidd
Peter Hutterer
Jon Turney
Julien Cristau
Karol Kosik
Emil Velikov
Qiang Yu
Hans De Goede
Ben Crocker