Add options for DRI{1,2,3}
shmfence is required for DRI3
libdrm is required for any DRI{1,2,3}
Consolidate calls to dependency('libdrm')
Set WITH_LIBDRM when building with libdrm
v2:
Initialize libxserver_dri3 to []
Manually flatten libxserver, since meson doesn't (currently)
Use version_compare rather than circumloctions with dependency()
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
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>
I clearly hadn't run ninja test, since fb no longer had any of the fb
symbols in it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.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>
I converted Xorg when meson 0.40 came out, but fumbled my grep and
forgot that I had instances of the .extract_all_objects() workaround
in dixmods, too.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Stone <daniels@collabora.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>
The number for it was merged to drm_mode.h in kernel 4.7, and the
output_names[] array just requires that we slot in new strings in
order.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The build defines these, so having the defaults is just a way for the
build system's configuration to get out of sync with the code.
v2: Drop #ifndefs around the other two defines.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.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>
E.g. because Xinerama is enabled.
Fixes crash on startup and wrong colours in that case.
Bugzilla: https://bugs.freedesktop.org/100293
Bugzilla: https://bugs.freedesktop.org/100294
Fixes: 62f4405257 ("xfree86/modes: Move gamma initialization to
xf86RandR12Init12 v2")
Tested-by: Mariusz Bialonczyk <manio@skyboo.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Despite all the careful planning of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending connector's
link-status to BAD and send the userspace a hotplug event. This may
happen right after a modeset or later on.
Upon receiving a hot-plug event, we iterate through the connectors to
re-apply the currently-set mode on all the connectors that have a
link-status property set to BAD. The kernel may be able to get the
link to work by dropping to using a lower link bpp (with the same
display bpp). However, the modeset may fail if the kernel has pruned
the mode, so to make users aware of this problem a warning is outputed
in the logs to warn about having a potentially-black display.
This patch does not modify the current behaviour of always propagating
the events to the randr clients. This allows desktop environments to
re-probe the connectors and select a new resolution based on the new
(currated) mode list if a mode disapeared. This behaviour is expected in
order to pass the Display Port compliance tests.
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. modesetting was blindly asserting
it supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Stone <daniels@collabora.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>
The X Server never generates a global config.h, and instead all these
paths are including dix-config.h or xorg-config.h.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Multiple calls to xf86EdidMonitorSet (which can be triggered e.g. by
running xrandr) would potentially keep adding the same modes, causing
the Monitor->Modes list to keep growing larger and using up more memory.
Fix this by calling xf86PruneDuplicateModes after adding the modes
returned by xf86DDCGetModes. This makes sure there's only one instance
of each unique mode in the list.
v2:
* Replace semicolon with {} for empty for loop (Emil Velikov)
* Slightly tweak commit log to avoid minor inaccuracy about what
xf86PruneDuplicateModes does
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99521
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Copied from Mesa with no modifications. Gives us Geminilake PCI IDs.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-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>
The linemarkers in the preprocessor output from gcc5 on Cygwin have
canonicalized paths to included files (e.g. xserver/build/../include/misc.h
is canonicalized to xserver/build/include/misc.h). (see gcc svn rev 210264,
which causes the transformation performed by -fcanonical-system-headers to
be applied to all include pathnames)
These canonicalized paths won't match $topdir, so sdksyms doesn't look at
the contents of those headers for sdk exported symbols.
Workaround this by canonicalizing all the paths we consider, using readlink.
v2:
Keep a cache of readlink results so it isn't quite so dreadfully slow.
Reviewed-by: Adam Jackson <ajax@redhat.com>
The code as written would match anything declared extern. _X_EXPORT is
what we really mean here. That's a macro, so check for what it expands
to and skip if not found.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Currently if modesetting ever fails to set a hardware cursor it will switch
to using a software cursor and never go back. Change this to only
permanently switch to a software cursor if -ENXIO is returned (which means
hardware cursors not supported), and to otherwise still try a hardware
cursor first every time a new one is set. This is needed because hardware
may be able to handle some cursors in hardware and others not, or virtual
hardware may be able to handle hardware cursors at some times and not
others.
Changes since v1, v2 and v3:
* take into account the switch to load_cursor_argb_check
* keep the permanent software cursor fall-back if -ENXIO is returned
* move parts of v3 into separate patches
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
Based on v4 by Alexandre Courbot <acourbot@nvidia.com>
There is currently no reliable way to report failure to set a HW
cursor. Still such failures can happen if e.g. the MODE_CURSOR DRM
ioctl fails (which currently happens at least with modesetting on Tegra
for format incompatibility reasons).
As failures are currently handled by setting the HW cursor size to
(0,0), the fallback to SW cursor will not happen until the next time the
cursor changes and xf86CursorSetCursor() is called again. In the
meantime, the cursor will be invisible to the user.
This patch addresses that by adding _xf86CrtcFuncs::set_cursor_check and
_xf86CursorInfoRec::ShowCursorCheck hook variants that return booleans.
This allows to propagate errors up to xf86CursorSetCursor(), which can
then fall back to using the SW cursor immediately.
v5:
- Removed parts of patch already committed as part of 14c21ea1.
- Adjusted code slightly to match surrounding code.
- Effectively reverted af916477 which is made unnecessary by this patch.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
Based on v4 by Alexandre Courbot <acourbot@nvidia.com>
There is currently no reliable way to report failure to set a HW
cursor. Still such failures can happen if e.g. the MODE_CURSOR DRM
ioctl fails (which currently happens at least with modesetting on Tegra
for format incompatibility reasons).
As failures are currently handled by setting the HW cursor size to
(0,0), the fallback to SW cursor will not happen until the next time the
cursor changes and xf86CursorSetCursor() is called again. In the
meantime, the cursor will be invisible to the user.
This patch addresses that by adding _xf86CrtcFuncs::set_cursor_check and
_xf86CursorInfoRec::ShowCursorCheck hook variants that return booleans.
This allows to propagate errors up to xf86CursorSetCursor(), which can
then fall back to using the SW cursor immediately.
v5: Updated the patch to apply to current git HEAD, split up into two
patches (server and modesetting driver) and adjusted the code slightly
to match surrounding code. I also removed the new exported function
ShowCursorCheck(), as instead just changing ShowCursor() to return Bool
should not affect its current callers.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
xf86RecolorCursor() may be called directly from XRecolorCursor as well
as from xf86ScreenSetCursor(). In the latter case, the input lock is
already held, but not for the former and so we need to add a wrapper
function that acquires the input lock before performing
xf86RecolorCursor()
References: https://bugs.freedesktop.org/show_bug.cgi?id=99358
This can happen when a module fails to load:
Program received signal SIGSEGV, Segmentation fault.
UnloadModule (_mod=0x5555559d9280) at ../../../../hw/xfree86/loader/loadmod.c:848
848 name = mod->VersionInfo->modname;
(gdb) bt
#0 UnloadModule (_mod=0x5555559d9280) at ../../../../hw/xfree86/loader/loadmod.c:848
#1 0x00005555555ddd1b in LoadModule (module=module@entry=0x5555559c7ce0 "fbdev", options=0x0, modreq=modreq@entry=0x0, errmaj=errmaj@entry=0x7fffffffe8ec) at ../../../../hw/xfree86/loader/loadmod.c:824
#2 0x00005555555edfe9 in xf86LoadModules (list=list@entry=0x5555559dcf50, optlist=optlist@entry=0x0) at ../../../../hw/xfree86/common/xf86Init.c:1506
#3 0x00005555555ee7bc in InitOutput (pScreenInfo=pScreenInfo@entry=0x5555559abf80 <screenInfo>, argc=argc@entry=4, argv=argv@entry=0x7fffffffeb18) at ../../../../hw/xfree86/common/xf86Init.c:484
#4 0x00005555555a885c in dix_main (argc=4, argv=0x7fffffffeb18, envp=<optimized out>) at ../../dix/main.c:197
#5 0x00007ffff5d582b1 in __libc_start_main (main=0x555555593130 <main>, argc=4, argv=0x7fffffffeb18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffeb08) at ../csu/libc-start.c:291
#6 0x000055555559316a in _start ()
Fixes: 8e83eacb9e ("loader: Remove unused path and name from ModuleDescPtr")
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
V2:
1. update comment
2. check bustype if PCI
3. configure add libdrm version check for drmGetDevice
Get PCI information from info->fd with drmGetDevice instead of
assuming the info->fd is the first entity of scrn which is not
true for multi entities scrn.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Just a waste of memory. Path was never referenced at all, and name was
only used when unloading the module; we can just as well get the
module's internal idea of its name from VersionInfo.
Reviewed-by: Julien Cristau <jcristau@debian.org>
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>
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>
This is a preparation patch to allow easier usage of init_one_component
outside of xf86RandR12CrtcInitGamma.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
When using secondary GPU outputs the primary GPU's blockhandler
will copy changes from its framebuffer to a pixmap shared with the
secondary GPU.
In reverse prime setups the secondary GPU's blockhandler will do another
copy from the shared pixmap to its own framebuffer.
Before this commit, if the primary GPU's blockhandler would run after
the secondary GPU's blockhandler and no events were pending, then the
secondary GPU's blockhandler would not run until some events came in
(WaitForSomething() would block in the poll call), resulting in the
secondary GPU output sometimes showing stale contents (e.g. a just closed
window) for easily up to 10 seconds.
This commit fixes this by setting the timeout passed into the
blockhandler to 0 if any shared pixmaps were updated by the primary GPU,
forcing an immediate re-run of all blockhandlers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
When using reverse prime we do 2 copies, 1 from the primary GPU's
framebuffer to a shared pixmap and 1 from the shared pixmap to the
secondary GPU's framebuffer.
This means that on the primary GPU side the copy MUST be finished,
before we start the second copy (before the secondary GPU's driver
starts processing the damage on the shared pixmap).
This fixes secondary outputs sometimes showning (some) old fb contents,
because of the 2 copies racing with each other, for an example of
what this looks like see:
https://fedorapeople.org/~jwrdegoede/IMG_20160915_130555.jpg
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes XRRGetOutputPrimary and xrandr not reporting a primary output after
startup. This was especially confusing when an output was explicitly
marked as primary using Option "Primary" in Section "Monitor".
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Move ms_flush_drm_events out of GLAMOR ifdef.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97586
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This fixes glxgears running at 1 fps when fully covering a slave-output
and the modesetting driver is used for the master gpu.
Reported-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
99% of the code in ms_covering_crtc is video-driver agnostic. Add a
screen_is_ms parameter when when FALSE skips the one ms specific check,
this will allow calling ms_covering_crtc on slave GPUs.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Implement the CreateBuffer2 / DestroyBuffer2 / CopyRegion2 DRI2InfoRec
version 9 callbacks, this is necessary for being an offload source
provider with DRI2.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
If a frontbuffer drawable already has a pixmap, make sure it was created
on the right screen.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently with PRIME if we detect a secondary GPU,
we switch to using SW cursors, this isn't optimal,
esp for the intel/nvidia combinations, we have
no choice for the USB offload devices.
This patch checks on each slave screen if hw
cursors are enabled, and also calls set cursor
and move cursor on all screens.
Cc: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
When a slave-output is rotated the transformation is done on the blit
from master to slave GPU, so crtc->transform_in_use is not set, but we
still need to adjust the mouse position for things to work.
This commit modifies xf86_crtc_transform_cursor_position to not rely
on crtc->f_framebuffer_to_crtc, so that it can be used with GPU screens
too and always calls it for crtcs with any form of rotation.
Note not using crtc->f_framebuffer_to_crtc means that crtc->transform
will not be taken into account, that is ok, because when we've a transform
active hw-cursors are not used and xf86_crtc_transform_cursor_position
will never get called.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
xf86_crtc_rotate_coord should be the exact inverse operation of
xf86_crtc_rotate_coord_back, but when calculating x / y for 90 / 270
degrees rotation it was using height to calculate x / width to calculate y,
instead of the otherway around.
This was likely not noticed before since xf86_crtc_rotate_coord
until now was only used with cursor_info->MaxWidth and
cursor_info->MaxHeight, which are usally the same.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The CurrentCursor is always attached to the master GPU.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This is a preparation patch for adding prime hw-cursor support.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The "if (pixmap) ..." block this commit removes is inside an
"if (pixmap == NULL) ..." block, so it will never execute.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Remove unused arguments from ms_covering_crtc, make it static as it is
only used in vblank.c.
While at it also change its first argument from a ScrnInfoPtr to a
ScreenPtr, this makes the next patch in this patch-set cleaner.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
glamor_fd_from_pixmap() may return a tiled bo, which is not suitable
for sharing with another GPU as tiling usually is GPU specific.
Switch to glamor_shareable_fd_from_pixmap(), which always returns a
linear bo. This fixes mis-rendering when running the mode setting
driver on the master gpu in a dual-gpu setup and running an opengl
app with DRI_PRIME=1.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
The common page flip handle framework can be shared with DRI2
page flip.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
When Xorg gets started directly from a wayland-gdm the crtc still has the
wayland hw cursor set. Combine this with Xorg immediately falling back to
a sw cursor because a slave-output has a monitor attached at startup; and
we end up with the wayland hardware cursor overlay fixed in its last
position + the Xorg sw cursor resulting in 2 cursors.
This commit fixes this by hiding any left-over cursors when initializing
the crtc.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
The modesetting driver may be driving 2 screens (slave and master
gpu), which may have different behavior wrt hardware cursor support.
So stop using static variables and instead store the hw-cursor support
related data in a per screen struct. While at it actually make it per
crtc data as in theory different crtc's could have different hw-cursor
support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
We're happily printing the error to stdout but not which module caused it...
That's in the Xorg.log but that's at least one click away.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Xorg -configure relies on the bus implementation, e.g.
xf86pciBus.c to call xf86AddBusDeviceToConfigure(). The new
xf86platformBus code does not have support for this.
Almost all drivers support both the xf86platformBus and xf86pciBus
nowadays, and the generic xf86Bus xf86CallDriverProbe() function
prefers the new xf86platformBus probe method when available.
Since the platformBus paths do not call xf86AddBusDeviceToConfigure()
this results in Xorg -configure failing with the following error:
"No devices to configure. Configuration failed.".
Adding support for the xf86Configure code to xf86platformBus.c
is non trivial and since we advise users to normally run without
any Xorg.conf at all not worth the trouble.
However some users still want to use Xorg -configure to generate a
template config file, this commit implements a minimal fix to make
things work again for PCI devices by skipping the platform
probe method when xf86DoConfigure is set.
This has been tested on a system with integrated intel graphics,
with both the intel and modesetting drivers and restores Xorg -configure
functionality on both cases.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This loop was written in a buggy style, causing a NULL driver ptr to be
passed to copyScreen(). copyScreen() only uses that to generate an
identifier string, so this is mostly harmless on systems that accept
NULL for asprintf() "%s" format. (the generated identifiers are off
by one wrt the driver names and the last one contains NULL.
For systems that don't accept NULL for '%s' this would cause a
segmentation fault when this code is used (no xorg.conf, but partial
config in xorg.conf.d for instance).
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Keith Packard <keithp@keithp.com>
In function xf86VGAarbiterScrnInit when the "pEnt->bus.type" is
BUS_PLATFORM, the "pScrn->vgaDev" won't be set, so the "pScrn->vgaDev" is
equal to zero.
The variable "rsrc_decodes" in function "xf86VGAarbiterAllowDRI" is not
initialized. So it will occur error when "pScrn->vgaDev == 0", and
"vga_count > 1". For this case, as "pScrn->vgaDev == 0", the function
"pci_device_vgaarb_get_info" will only set the value of "vga_count",
but won't set the value of "rsrc_decodes", so it will has two different
return values for function "xf86VGAarbiterAllowDRI" in different
platforms. One platform will return TRUE, as the "rsrc_decodes" 's
default value is 0, but another platform will return FALSE, as the
"rsrc_decodes" 's default value is "32767", this will cause disable
direct rendering.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96937
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Any code called from the driver ScreenInit may want to refer to
pScrn->pScreen. As the function passed to AddScreen is the first place
the DDX sees a new screen, the generic code needs to make sure that
value is set before passing control to the video driver's
initialization code.
This was found by running a driver which didn't bother to set this
value when the initial colormap was installed; xf86RandR12LoadPalette
tried to use pScrn->pScreen and crashed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97124
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
This is a problem for the libinput driver that uses the same context across
multiple devices. The driver may be halfway through setting up an input device
(and the only way to do so is to add it to libinput) when the input thread
comes in an reads events. This then causes mayhem when data is dereferenced
that hasn't been set up yet.
In my case the cause was the call to libinput_path_remove_device() inside
preinit racing with evdev_dispatch_device() handling of ENODEV. The sequence
was:
- thread 2 gets an event and calls evdev_dispatch_device()
- thread 1 calls libinput_path_remove_device() which sets the device->source
to NULL
- thread 2 reads from the fd, gets ENODEV and now removes the device->source,
dereferencing the null-pointer
This is the one I could reproduce the most, but there are other potential
pitfalls that affect any driver that uses the same fd for multiple devices.
Avoid all this and wrap PreInit into the lock.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
If a device couldn't be enabled we left the lock hanging.
This patch also removes the leftover OsReleaseSignals() call, now unnecessary.
Note that input_unlock() is later than previously OsReleaseSignals().
RemoveDevice() manipulates the input device and its file descriptors, it's
safer to put the input_unlock() call after RemoveDevice() to avoid events
coming in while the device is being removed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Just use the RandR gamma ramp directly.
Fixes random on-monitor colours with drivers which don't call
xf86HandleColormaps, e.g. modesetting.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97154
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Embarassingly, it looks like I introduced this dead function in
commit 13c7d53df8 a year ago.
Nothing ever used it, not even then.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Instead of breaking the former when the driver supports the latter,
hook them up so that the hardware LUTs reflect the combination of the
current colourmap and gamma states. I.e. combine the colourmap, the
global gamma value/ramp and the RandR 1.2 per-CRTC gamma ramps into one
combined LUT per CRTC.
Fixes e.g. gamma sliders not working in games.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27222
v2:
* Initialize palette_size and palette struct members, fixes crash on
server startup.
v3:
* Free randrp->palette in xf86RandR12CloseScreen, fixes memory leak.
v4:
* Call CMapUnwrapScreen if xf86RandR12InitGamma fails (Emil Velikov).
* Still allow xf86HandleColormaps to be called with a NULL loadPalette
parameter in the xf86_crtc_supports_gamma case.
v5:
* Clean up inner loops in xf86RandR12CrtcComputeGamma (Keith Packard)
* Move palette update out of per-CRTC loop in xf86RandR12LoadPalette
(Keith Packard)
v6:
* Handle reallocarray failure in xf86RandR12LoadPalette (Keith Packard)
Reviewed-by: Keith Packard <keithp@keithp.com>
This would normally return the same values the core RandR code passed to
xf86RandR12CrtcSetGamma before, which is rather pointless. The only
possible exception would be if a driver tried initializing
crtc->gamma_red/green/blue to reflect the hardware LUT state on startup,
but that can't work correctly if whatever set the LUT before the server
started was running at a different depth.
Even the pointless round-trip case will no longer work with the
following change.
Reviewed-by: Keith Packard <keithp@keithp.com>
RRCrtcGammaSetSize cannot be used yet in xf86InitialConfiguration,
because randr_crtc isn't allocated yet at that point, but a following
change will require RRCrtcGammaSetSize to be called from
xf86RandR12CrtcInitGamma.
v2:
* Bail from xf86RandR12CrtcInitGamma if !crtc->funcs->gamma_set (Keith
Packard)
Reviewed-by: Keith Packard <keithp@keithp.com>
This uses the wrapper in case we need to emulate poll with select
as we do on Windows.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
ATTR_KEY maps to ID_INPUT_KEY which is set for any device with keys.
ID_INPUT_KEYBOARD and thus ATTR_KEYBOARD is set for devices that are actual
keyboards (and have a set of expected keys).
Hand-written match rules may only apply ID_INPUT_KEYBOARD, so make sure we
match on that too.
Arguably we should've been matching on ATTR_KEYBOARD only all along but
changing that likely introduces regressions.
Reported-by: Marty Plummer <netz.kernel@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This error code can mean we're submitting more rects at once than the
driver can handle. If that happens, resubmit one at a time.
v2: Make the rect submit loop more error-proof (Walter Harms)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michael Thayer <michael.thayer@oracle.com>
This removes the last uses of fd_set from the server interfaces
outside of the OS layer itself.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
With no users of the interface needing the readmask anymore, we can
remove it from the argument passed to these functions.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is a cleanup, proposed by Adam Jackson, but wasn't merged with
the original NotifyFD changes.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Remove code in xf86Wakeup for dealing with other input and switch to
using the new NotifyFd interface.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This new libXfont API eliminates exposing internal X server symbols to
the font library, replacing those with a struct full of the entire API
needed to use that library.
v2: Use libXfont2 instead of libXfont_2
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The intent here was that fallback drivers would be at the end of the
list in order, but if a fallback driver happened to be at the end of the
list already that's not what would happen. Rather than open-code
something smarter, just use qsort.
Note that qsort puts things in ascending order, so somewhat backwardsly
fallbacks are greater than native drivers, and vesa is greater than
modesetting.
v2: Use strcmp to compare non-fallback drivers so we get a predictable
result if your libc's qsort isn't stable (Keith Packard)
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
/dev/vc/0 is a devfs thing which is long dead, so stop trying to open
/dev/vc/0, besides being a (small) code cleanup this will also fix the
"parse_vt_settings: Cannot open /dev/tty0 (%s)\n" error message to
display the actual error, rather then the -ENOENT from also trying
/dev/vc/0.
BugLink: https://patchwork.freedesktop.org/patch/8768/
Reported-by: Chad Versace <chad.versace@linux.intel.com>
Suggested-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Commit 80e64dae: "modesetting: Implement PRIME syncing as a sink" originally was
supposed to have this line, but it was dropped as part of the merge process.
Foregoing the NULL assignment causes a ton of problems with dereferencing
uninitialized memory.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
In newer laptops with switchable graphics, the GPU may have 0 outputs,
in this case the modesetting driver should still load if the GPU is
SourceOffload capable, so that it can be used as an offload source provider.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
When a card has import capability it can be an offload _sink_, not
a source and vice versa for export capability.
This commit fixes the modesetting driver to properly set these
capabilities, this went unnoticed sofar because most gpus have both
import and export capability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Server GPUs often have a VNC feature attached to allow remote console.
The controller implementing this feature is usually not very powerful,
and we can easily swamp it with work. This is made somewhat worse by
damage over-reporting the size of the dirty region, and a whole lot
worse by applications (or shells) that update the screen with identical
pixel content as was already there.
Fix this by double-buffering the shadow fb, using memcmp to identify
dirty tiles on each update pass. Since both shadows are in host memory
the memcmp is cheap, and worth it given the win in network bandwidth.
The tile size is somewhat arbitrarily chosen to be one cacheline wide at
32bpp on Intel Core.
By default we enable this behaviour for (a subset of) known server GPUs;
the heuristic could use work.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
24bpp front buffers tend to be the least well tested path for client
rendering. On the qemu cirrus emulation, and on some Matrox G200 server
chips, the hardware can't do 32bpp at all. It's better to just allocate
a 32bpp shadow and downconvert in the upload hook than expose a funky
pixmap format to clients.
[ajax: Ported from RHEL and separate modesetting driver, lifted kbpp
into the drmmode struct, cleaned up commit message, fixed 16bpp]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlied <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
[hdegoede@redhat.com: rebase, also use kbpp for rotate shadow fb]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
With the previous patch, the modesetting driver can now return whether
the driver supports hw cursor. However, it alone doesn't suffice,
unfortunately. drmmode_load_cursor_argb_check() is called in the
following chain:
xf86CursorSetCursor()
-> xf86SetCursor()
-> xf86DriverLoadCursorARGB()
-> xf86_load_cursor_argb()
-> xf86_crtc_load_cursor_argb()
-> drmmode_load_cursor_argb_check()
*but* at first with drmmode_crtc->cursor_up = FALSE. Then the
function doesn't actually set the cursor but returns TRUE
unconditionally. The actual call of drmmode_set_cursor() is done at
first via the show_cursor callback, and there is no check of sw cursor
fallback any longer at this place. Since it's called only once per
cursor setup, so the xserver still thinks as if the hw cursor is
supported.
This patch is an ad hoc fix to correct the behavior somehow: it does
call drmmode_set_cursor() at the very first time even if cursor_up is
FALSE, then quickly hides again. In that way, whether the hw cursor
is supported is evaluated in the right place at the right time.
Of course, it might be more elegant if we have a more proper mechanism
to fall back to sw cursor at any call path. But it'd need more
rework, so I leave this workaround as is for now.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The modesetting driver still has an everlasting bug of invisible
cursor on cirrus and other KMS drivers where no hardware cursor is
supported. This patch is a part of an attempt to address it.
This patch particularly converts the current load_cursor_argb callback
of modesetting driver to load_cursor_argb_check so that it can return
whether the driver handles the hw cursor or falls back to the sw
cursor.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
[hdegoede@redhat.com: Add extra comment suggested by Kenneth]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The error value isn't always -EINVAL, e.g. the kernel drm core returns
-ENXIO when the corresponding ops doesn't exist. Without this fix,
DRM_IOCTL_MODE_CURSOR2 would be dealt as success even if it
shouldn't.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Implements (Start/Stop)FlippingPixmapTracking, PresentSharedPixmap, and
RequestSharedPixmapNotifyDamage, the source functions for PRIME
synchronization and double buffering. Allows modesetting driver to be used
as a source with PRIME synchronization.
v1: N/A
v2: N/A
v3: N/A
v4: Initial commit
v5: Move disabling of reverse PRIME on sink to sink commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reverse PRIME seems to be designed with discrete graphics as a sink in
mind, designed to do an extra copy from sysmem to vidmem to prevent a
discrete chip from needing to scan out from sysmem.
The criteria it used to detect this case is if we are a GPU screen and
Glamor accelerated. It's possible for i915 to fulfill these conditions,
despite the fact that the additional copy doesn't make sense for i915.
Normally, you could just set AccelMethod = none as an option for the device
and call it a day. However, when running with modesetting as both the sink
and the source, Glamor must be enabled.
Ideally, you would be able to set AccelMethod individually for devices
using the same driver, but there seems to be a bug in X option parsing that
makes all devices on a driver inherit the options from the first detected
device. Thus, glamor needs to be enabled for all or for none until that bug
(if it's even a bug) is fixed.
Nonetheless, it probably doesn't make sense to do the extra copy on i915
even if Glamor is enabled for the device, so this is more user friendly by
not requiring users to disable acceleration for i915.
v1: N/A
v2: N/A
v3: N/A
v4: Initial commit
v5: Unchanged
v6: Rebase onto ToT
v7: NULL check and free drmVersionPtr
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
UDL (USB 2.0 DisplayLink DRM driver) and other drivers for USB transport devices
have strange semantics when it comes to vblank events, due to their inability to
get the actual vblank info.
When doing a page flip, UDL instantly raises a vblank event without waiting for
vblank. It also has no support for DRM_IOCTL_WAIT_VBLANK, and has some strange
behavior with how it handles damage when page flipping.
It's possible to get something semi-working by hacking around these issues,
but even then there isn't much value-add vs single buffered PRIME, and it
reduces maintainability and adds additional risks to the modesetting driver
when running with more well-behaved DRM drivers.
Work needs to be done on UDL in order to properly support synchronized
PRIME. For now, just blacklist it, causing RandR to fall back to
unsynchronized PRIME.
This patch originally blacklisted UDL by name, but it was pointed out that there
are other USB transport device drivers with similar limitations, so it was
expanded to blacklist all USB transport devices.
v1: N/A
v2: N/A
v3: Initial commit
v4: Move check to driver.c for consistency/visibility
v5: Refactor to accomodate earlier changes
v6: Rebase onto ToT
v7: Expand to blacklist all USB transport devices, not just UDL
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
DPMS would prevent page flip / vblank events from being raised, freezing
the screen until PRIME flipping was reinitialized. To handle DPMS cleanly,
suspend PRIME page flipping when DPMS mode is not on, and resume it when
DPMS mode is on.
v1: Initial commit
v2: Moved flipping_active check from previous commit to here
v3: Unchanged
v4: Unchanged
v5: Move flipping_active check to sink support commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
Implements (Enable/Disable)SharedPixmapFlipping and
SharedPixmapNotifyDamage, the sink functions for PRIME synchronization and
double buffering. Allows modesetting driver to be used as a sink with PRIME
synchronization.
Changes dispatch_slave_dirty to flush damage from both scanout pixmaps.
Changes drmmode_set_scanout_pixmap*() functions to
drmmode_set_target_scanout_pixmap*() that take an additional parameter
PixmapPtr *target. Then, treat *target as it did prime_pixmap. This allows
me to use it to explicitly set both prime_pixmap and prime_pixmap_back
individually. drmmode_set_scanout_pixmap() without the extra parameter
remains to cover the single-buffered case, but only works if we aren't
already double buffered.
driver.c:
Add plumbing for rr(Enable/Disable)SharedPixmapFlipping and
SharedPixmapNotifyDamage.
Change dispatch_dirty_crtc to dispatch_dirty_pixmap, which functions the
same but flushes damage associated with a ppriv instead of the crtc, and
chanage dispatch_slave_dirty to use it on both scanout pixmaps if
applicable.
drmmode_display.h:
Add flip_seq field to msPixmapPrivRec to keep track of the event handler
associated with a given pixmap, if any.
Add wait_for_damage field to msPixmapPrivRec to keep track if we have
requested a damage notification from the source.
Add enable_flipping field to drmmode_crtc_private_rec to keep track if
flipping is enabled or disabled.
Add prime_pixmap_back to drmmode_crtc_private_rec to keep track of back
buffer internally.
Add declarations for drmmode_SetupPageFlipFence(),
drmmode_EnableSharedPixmapFlipping(),
drmmode_DisableSharedPixmapFlipping, drmmode_SharedPixmapFlip(), and
drmmode_SharedPixmapPresentOnVBlank().
Move slave damage from crtc to ppriv.
drmmode_display.c:
Change drmmode_set_scanout_pixmap*() functions to
drmmode_set_target_scanout_pixmap*() that take an additional parameter
PixmapPtr *target for explicitly setting different scanout pixmaps.
Add definitions for functions drmmode_SharedPixmapFlip(),
drmmode_SharedPixmapPresentOnVBlank(),
drmmode_SharedPixmapPresent(),
drmmode_SharedPixmapVBlankEventHandler(),
drmmode_SharedPixmapVBlankEventAbort(),
drmmode_EnableSharedPixmapFlipping(), and
drmmode_DisableSharedPixmapFlipping,
drmmode_InitSharedPixmapFlipping(), and
drmmode_FiniSharedPixmapFlipping, along with struct
vblank_event_args.
The control flow is as follows:
pScrPriv->rrEnableSharedPixmapFlipping() makes its way to
drmmode_EnableSharedPixmapFlipping(), which sets enable_flipping to
TRUE and sets both scanout pixmaps prime_pixmap and
prime_pixmap_back.
When setting a mode, if prime_pixmap is defined, modesetting
driver will call drmmode_InitSharedPixmapFlipping(), which if
flipping is enabled will call drmmode_SharedPixmapPresent() on
scanout_pixmap_back.
drmmode_SharedPixmapPresent() requests that for the source to
present on the given buffer using master->PresentSharedPixmap(). If
it succeeds, it will then attempt to flip to that buffer using
drmmode_SharedPixmapFlip(). Flipping shouldn't fail, but if it
does, it will raise a warning and try drmmode_SharedPixmapPresent()
again on the next vblank using
drmmode_SharedPixmapPresentOnVBlank().
master->PresentSharedPixmap() could fail, in most cases because
there is no outstanding damage on the mscreenpix tracked by the
shared pixmap. In this case, drmmode_SharedPixmapPresent() will
attempt to use master->RequestSharedPixmapNotifyDamage() to request
for the source driver to call slave->SharedPixmapNotifyDamage() in
response to damage on mscreenpix. This will ultimately call
into drmmode_SharedPixmapPresentOnVBlank() to retry
drmmode_SharedPixmapPresent() on the next vblank after
accumulating damage.
drmmode_SharedPixmapFlip() sets up page flip event handler by
packing struct vblank_event_args with the necessary parameters, and
registering drmmode_SharedPixmapVBlankEventHandler() and
drmmode_SharedPixmapVBlankEventAbort() with the modesetting DRM
event handler queue. Then, it uses the drmModePageFlip() to flip on
the next vblank and raise an event.
drmmode_SharedPixmapPresentOnVBlank() operates similarly to
drmmode_SharedPixmapFlip(), but uses drmWaitVBlank() instead of
drmModePageFlip() to raise the event without flipping.
On the next vblank, DRM will raise an event that will ultimately be
handled by drmmode_SharedPixmapVBlankEventHandler(). If we flipped,
it will update prime_pixmap and prime_pixmap_back to reflect that
frontTarget is now being displayed, and use
drmmode_SharedPixmapPresent(backTarget) to start the process again
on the now-hidden shared pixmap. If we didn't flip, it will just
use drmmode_SharedPixmapPresent(frontTarget) to start the process
again on the still-hidden shared pixmap.
Note that presentation generally happens asynchronously, so with
these changes alone tearing is reduced, but we can't always
guarantee that the present will finish before the flip. These
changes are meant to be paired with changes to the sink DRM driver
that makes flips wait on fences attached to dmabuf backed buffers.
The source driver is responsible for attaching the fences and
signaling them when presentation is finished.
Note that because presentation is requested in response to a
vblank, PRIME sources will now conform to the sink's refresh rate.
At teardown, pScrPriv->rrDisableSharedPixmapFlipping() will be
called, making its way to drmmode_FiniSharedPixmapFlipping().
There, the event handlers for prime_pixmap and prime_pixmap_back
are aborted, freeing the left over parameter structure. Then,
prime_pixmap and prime_pixmap back are unset as scanout pixmaps.
Register and tear down slave damage per-scanout pixmap instead of
per-crtc.
v1: Initial commit
v2: Renamed PresentTrackedFlippingPixmap to PresentSharedPixmap
Renamed flipSeq to flip_seq
Warn if flip failed
Use SharedPixmapNotifyDamage to retry on next vblank after damage
v3: Refactor to accomodate moving (rr)StartFlippingPixmapTracking and
(rr)(Enable/Disable)SharedPixmapFlipping to rrScrPrivRec from ScreenRec
Do damage tracking on both scanout pixmaps
v4: Tweaks to commit message
v5: Revise for internal storage of prime pixmap ptrs
Move disabling for reverse PRIME from source commit to here
Use drmmode_set_target_scanout_pixmap*() to set scanout pixmaps
internally to EnableSharedPixmapFlipping().
Don't support flipping if ms->drmmode.pageflip == FALSE.
Move flipping_active check to this commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
ms->drmmode.pageflip was only loaded from options if ms->drmmode.glamor was
defined, otherwise it would always assume FALSE.
PRIME Synchronization requires ms->drmmode.pageflip even if we aren't using
glamor, so load it unconditionally.
v1: N/A
v2: N/A
v3: N/A
v4: N/A
v5: Initial commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
drmmode_set_scanout_pixmap_(cpu/gpu) would only do teardown if ppix ==
NULL. This meant that if there were consecutive calls to
SetScanoutPixmap(ppix != NULL) without calls to SetScanoutPixmap(ppix ==
NULL) in between, earlier calls would be leaked. RRReplaceScanoutPixmap()
does this today.
Instead, when setting a scanout pixmap, always do teardown of the existing
scanout pixmap before setting up the new one. Then, if there is no new one
to set up, stop there.
This maintains the previous behavior in all cases except those with
multiple consecutive calls to SetScanoutPixmap(ppix != NULL).
v1: N/A
v2: N/A
v3: N/A
v4: N/A
v5: Initial commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
modesetting relied on randr_crtc->scanout_pixmap being consistent with
calls to SetScanoutPixmap, which is very fragile and makes a lot of
assumptions about the caller's behavior.
For example, RRReplaceScanoutPixmap(), when dropping off with !size_fits,
will set randr_crtc->scanout_pixmap = NULL and then call SetScanoutPixmap.
Without this patch, drmmode_set_scanout_pixmap_(cpu/gpu) will think that
there is no scanout pixmap to tear down, because it's already been set to
NULL.
By keeping track of the scanout pixmap in its internal state, modesetting
can avoid these types of bugs and reduce constraints on calling
conventions.
v1: N/A
v2: N/A
v3: N/A
v4: N/A
v5: Initial commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
Changes PRIME to use double buffering and synchronization if all required
driver functions are available.
rrcrtc.c:
Changes rrSetupPixmapSharing() to use double buffering and
synchronization in the case that all required driver functions are
available. Otherwise, falls back to unsynchronized single buffer.
Changes RRCrtcDetachScanoutPixmap() to properly clean up in the case of
double buffering.
Moves StopPixmapTracking() from rrDestroySharedPixmap() to
RRCrtcDetachScanoutPixmap().
Changes RRReplaceScanoutPixmap() to fail if we are using double buffering,
as it would need a second ppix parameter to function with double buffering,
and AFAICT no driver I've implemented double buffered source support in uses
RRReplaceScanoutPixmap().
randrstr.h:
Adds scanout_pixmap_back to struct _rrCrtc to facilitate PRIME
double buffering.
xf86Crtc.h:
Adds current_scanout_back to _xf86Crtc to facilitate detection
of changes to it in xf86RandR12CrtcSet().
xf86RandR12.c:
Changes xf86RandR12CrtcSet() to detect changes in
scanout_pixmap_back.
Adds scanout_pixmap_back to struct _rrCrtc to facilitate PRIME double
buffering.
v1: Initial commit
v2: Rename PresentTrackedFlippingPixmap to PresentSharedPixmap
v3: Refactor to accomodate moving (rr)StartFlippingPixmapTracking and
(rr)(Enable/Disable)SharedPixmapFlipping to rrScrPrivRec from ScreenRec
Add fallback if flipping funcs fail
v4: Detach scanout pixmap when destroying scanout_pixmap_back, to avoid
dangling pointers in some drivers
v5: Disable RRReplaceScanoutPixmap for double-buffered PRIME, it would need an
ABI change with support for 2 pixmaps if it were to be supported, but AFAICT
no driver that actually supports double-buffered PRIME uses it.
Refactor to use rrEnableSharedPixmapFlipping() as a substitute for
rrCrtcSetScanoutPixmap() in the flipping case.
Remove extraneous pSlaveScrPriv from DetachScanoutPixmap()
Remove extraneous protopix and pScrPriv from rrSetupPixmapSharing()
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
Consolidate to a single if/else statement and eliminate the redundant
local variable in_range and assignments to x/y.
Reviewed-by: Adam Jackson <ajax@redhat.com>
The driver can now specify exactly which aspects of the transform it
wants to handle via XF86DriverTransform* flags.
Since the driver can now choose whether it wants to receive transformed
or untransformed cursor coordinates, xf86CrtcTransformCursorPos no
longer needs to be available to drivers, so make it static.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Even if the driver is handling the transform, we still need to transform
the cursor position for clipping, otherwise we may hide the HW cursor
when the cursor is actually inside the area covered by the CRTC.
v2: Use crtc_x/y local variables for clarity
Reviewed-by: Adam Jackson <ajax@redhat.com>
[fix copied from 40191d82370e in xf86-video-ati]
Without this, we end up setting rotated CRTCs back to their previous
framebuffer right after we perform a rotation. Reproducer:
- Have two monitors connected at the same resolution
- Rotate one monitor from normal straight to inverted
- Watch as the monitor you didn't rotate either freezes or shows intense
flickering
Signed-off-by: Lyude <cpaul@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
If we're doing reverse-prime; or doing rotation the main fb is not used,
and there is no reason to add it in this case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
drmmode_set_mode_major() is the only user of drmmode->fb_id and will
create it if necessary.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This ensures the fb gets re-added when a shared pixmap is re-used for
a second drmmode_set_scanout_pixmap_cpu call.
Note currently the xserver never re-uses a shared pixmap in this way,
so this is mostly a sanity fix.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
drmmode_set_scanout_pixmap_gpu(pix) adds drmmod->fb_id through a call
to drmmode_xf86crtc_resize(), but on a subsequent
drmmode_set_scanout_pixmap_gpu(NULL) it would not remove the fb.
This keeps the crtc marked as busy, which causes the dgpu to not
being able to runtime suspend, after an output attached to the dgpu
has been used once. Which causes burning through an additional 10W
of power and the laptop to run quite hot.
This commit adds the missing remove fb call, allowing the dgpu to runtime
suspend after an external monitor has been plugged into the laptop.
Note this also makes drmmode_set_scanout_pixmap_gpu(NULL) match the
behavior of drmmode_set_scanout_pixmap_cpu(NULL) which was already
removing the fb.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
A single provider can be both a offload and source slave at the same time,
the use of seperate lists breaks in this case e.g. :
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 0 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 0 name:modesetting
xrandr --setprovideroutputsource 1 0x7b
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 1 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 1 name:modesetting
xrandr --setprovideroffloadsink 1 0x7b
xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 2 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Provider 2: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Not good. The problem is that the provider with id 0x46 now is on both
the output_slave_list and the offload_slave_list of the master screen.
This commit fixes this by unifying all 3 lists into a single slaves list.
Note that this does change the struct _Screen definition, so this is an ABI
break. I do not expect any of the drivers to actually use the removed / changed
fields so a recompile should suffice.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
As documented in xorg.conf(5), a value of ConstantDeceleration between 0
and 1 will speed up the pointer. However, values less than 1 actually
had no effect. Fix this.
Note that this bug only affected "ConstantDeceleration" as configured
through xorg.conf, not "Device Accel Constant Deceleration" as configured
through xinput. The property handler AccelSetDecelProperty() also did
not need to be changed, as it did not limit the values of the property.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=92766
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We want to notice that it's set, but still pass it through to dix.
Return 0 to indicate this.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
A new --with-fallback-input-driver=foo option allows selecting a
fallback driver for the server if the driver configured for the device
is not found. Note that this only applies when the device has a driver
assigned and that module fails to load, devices without a driver are
ignored as usual.
This avoids the situation where a configuration assigns e.g. the
synaptics driver but that driver is not available on the system,
resulting in a dead device. A fallback driver can at least provides some
functionality.
This becomes more important as we move towards making other driver true
leaf nodes that can be installed/uninstalled as requested. Specifically,
wacom and synaptics, a config that assigns either driver should be
viable even when the driver itself is not (yet) installed on the system.
It is up to the distributions to make sure that the fallback driver is
always installed. The fallback driver can be disabled with
--without-fallback-input-driver and is disabled by default on non-Linux
systems because we don't have generic drivers on those platforms.
Default driver on Linux is libinput, evdev is the only other serious
candidate here.
Sample log output:
[ 3274.421] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event4)
[ 3274.421] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad weird driver"
[ 3274.421] (II) LoadModule: "banana"
[ 3274.422] (WW) Warning, couldn't open module banana
[ 3274.422] (II) UnloadModule: "banana"
[ 3274.422] (II) Unloading banana
[ 3274.422] (EE) Failed to load module "banana" (module does not exist, 0)
[ 3274.422] (EE) No input driver matching `banana'
[ 3274.422] (II) Falling back to input driver `libinput'
.. server proceeds to assign libinput, init the device, world peace and rainbows
everywhere, truly what a sight. Shame about the banana though.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is an ABI break, in that we now pass NULL to a function that hasn't
accepted it before.
Alex Goins had a different patch for this but it wasn't symmetrical, it
freed something in a very different place than it allocated it, this
attempts to retain symmetry in the releasing of the backing bo.
v2: use a new toplevel API, though it still passes NULL to something
that wasn't expecting it.
v3: pass -1 instead of 0.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alex Goins <agoins at nvidia.com>
Not visible in the patch, but the same stanza is repeated below inside
the #ifdef GLXEXT. There's no reason to bother with checking it if we
built without GLXEXT so remove the unconditional one.
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The doc text is wrong at this point, input processing isn't going to
vary based on this, so we shouldn't say it does. The only thing this
_does_ get used for is DRI1 SwapBuffers (on everything but savage), and
if you disable it you're not going to get DRI1 at all, so we really
shouldn't even mention it.
Still, leave the option wired up to the parser so we don't break any
DRI1-driver-using setup relying on it being disabled, and so we don't
complain about unused options elsewhere.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
As the man page for the latter states:
The effects of signal() in a multithreaded process are unspecified.
We already have an interface to call sigaction() instead, use it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
No longer needed now that xf86CursorResetCursor is getting called for
each CRTC configuration change.
v2: Keep xf86_reload_cursors as a deprecated empty inline function
until all drivers stop calling it. (Adam Jackson)
Reviewed-by: Adam Jackson <ajax@redhat.com>
Fixes a crash on startup in the radeon driver's drmmode_show_cursor()
due to xf86_config->cursor == NULL, because no CRTC was enabled yet, so
xf86_crtc_load_cursor_image was never called.
(Also use scrn->pScreen instead of xf86ScrnToScreen(scrn))
v2: Set xf86_config->cursor at the beginning of xf86_load_cursor_image
instead of at the end.
Reviewed-by: Keith Packard <keithp@keithp.com>
Threaded input doesn't use SIGIO anymore, but existing drivers using
xf86BlockSIGIO and xf86ReleaseSIGIO probably want to lock the input
mutex during those operations. Provide inline functions to do this
which are marked as 'deprecated' so that drivers will get warnings
until they are changed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Oops. This didn't get removed when xfree86 was converted over to use
the input thread.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
threaded input can affect drivers that use OsBlockSIGIO when dealing
with cursors.
Signed-off-by: Keith Packard <keithp@keithp.com>
Requested-by: Peter Hutterer <peter.hutterer@who-t.net>
Use this instead of the (now deprecated) cursor pointer in the
xf86CrtcConfigRec.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Switch the XFree86 DDX over to threaded input
v2: Rewrite comment in xf86Helper about silken mouse
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The current SIGIO signal handler method, used at generation of input events,
has a bunch of oddities. This patch introduces an alternative way using a
thread, which is used to select() all input device file descriptors.
A mutex was used to control the access to input structures by the main and input
threads. Two pipes to emit alert events (such hotplug ones) and guarantee the
proper communication between them was also used.
Co-authored-by: Fernando Carrijo <fcarrijo@freedesktop.org>
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
v2: Fix non-Xorg link. Enable where supported by default.
This also splits out the actual enabling of input threads to
DDX-specific patches which follow
v3: Make the input lock recursive
v4: Use regular RECURSIVE_MUTEXes instead of rolling our own
Respect the --disable-input-thread configuration option by
providing stubs that expose the same API/ABI.
Respond to style comments from Peter Hutterer.
v5: use __func__ in inputthread debug and error mesages.
Respond to style comments from Peter Hutterer.
v6: use AX_PTHREAD instead of inlining pthread tests.
Suggested by Emil Velikov <emil.l.velikov@gmail.com>
v7: Use pthread_sigmask instead of sigprocmask when using threads
Suggested by Adam Jackson <ajax@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When this code was called from SIGIO, saving and restoring errno could
possibly have made sense in some strange environment. Now that this
will not be called from a signal handler, there is no reason to do that.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes all of the SIGIO handling support used for input
throughout the X server, preparing the way for using threads for input
handling instead.
Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
to stub functions input_lock/input_unlock so that we don't lose this
information.
xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO and OsReleaseSIGIO.
v2: Don't change locking order (Peter Hutterer)
v3: Comment weird && FALSE in xf86Helper.c
Leave errno save/restore in xf86ReadInput
Squash with stub adding patch (Peter Hutterer)
v4: Leave UseSIGIO config parameter so that
existing config files don't break (Peter Hutterer)
v5: Split a couple of independent patch bits out
of kinput.c (Peter Hutterer)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Not all display managers make it easy (or possible) to modify the
command line flags passed to the server, so add a way to get to it from
xorg.conf.
v2: Fix the FlagOptions list to not have IGLX after the terminator (Alan
Coopersmith)
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This makes the cursor pointer held by xf86Cursors.c get reset to NULL
whenever the cursor isn't displayed, and means that the reference
count held in xf86Cursor.c is sufficient to cover the reference in
xf86Cursors.c.
As HideCursor may be called in the cursor loading path after
UseHWCursor or UseHWCursorARGB when HARDWARE_CURSOR_UPDATE_UNHIDDEN
isn't set in the Flags field, the setting of the cursor pointer had to
be moved to the LoadCursor paths.
LoadCursorARGBCheck gets the cursor pointer, but LoadCursorImageCheck
does not. For LoadCursorImageCheck, I added a new function,
xf86CurrentCursor, which returns the current cursor. With this new
function, we can eliminate the cursor pointer from the
xf86CrtcConfigRec, once drivers are converted over to use it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Fix build without --enable-glamor.
Caught by the arm tinderbox.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The destination variable is never freed, thus we even plug some memory
leaks.
v2: Rebase against updated xf86CheckPrivs() helper.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Current message was quite off "file specified must be a relative path"
and alike. Just factor it out and use "path/file" as needed.
v2: Rework error message, drop "Using default", print actual arg value.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This moves the capabilites setting to after glamor is initialised, and
enables the offload caps in cases where they work. This enables DRI2
PRIME support with modesetting.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Slave GPUs don't have a root window to set this on, so don't.
This fixes some crashes I saw just playing around.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise ms_ent_priv will return NULL and things will fall apart.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For some reason a couple of the dirty functions in driver.c used 8
spaces per tab instead of 4 like the rest of the file. Fix this to make
it more consistent and give me more room to work in ms_dirty_update in
subsequent commits.
v1: N/A
v2: N/A
v3: N/A
v4: Initial commit
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The tablet pads have been separate kernel devices for a while now and
libwacom has labelled them with the udev ID_INPUT_TABLET_PAD for over a year
now. Add a new MatchIsTabletPad directive to apply configuration options
specifically to the Pad part of a tablet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Both radeon and amdgpu don't set the mode until the first blockhandler,
this means everything should be rendered on the screen correctly by
then.
This ports this code, it also removes the tail call of EnterVT from
ScreenInit, it really isn't necessary and causes us to set a dirty mode
with -modesetting always anyways.
v2: reorder set desired modes vs block handler as done for amdgpu.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This adds support using glamor for background None.
loosely based off the amdgpu code. relies on the glamor_finish code.
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
-Wlogical-op now tells us:
devices.c:1685:23: warning: logical ‘and’ of equal expressions
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
R_SP is also defined in <sys/ucontext.h> on m68k. Also remove duplicate
definitions.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Andreas Schwab <schwab@suse.de>
Rather than 'hacking' around symbol names and providing macros such as
'Local' just fold things and make the code more readable.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
... so that we can use it without the forward declaration. Plus we're
doing to reuse it in the next commit ;-)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Add the const notation to all the static storage as well as the
functions that use it - xf86getToken(), xf86getSubTokenWithTab(),
StringToToken() and xf86getStringToken().
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
All consumers have been ported to the root window callback, so this can
all be nuked.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Practically speaking, the EDID major version is never not 1.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We can call this more than once via xf86OutputSetEDID since hotplug is
actually a thing in RANDR 1.2, but xf86RegisterRootWindowProperty merely
adds the data to a list to be applied to the root at CreateWindow time,
so calls past the first (for a given screen) would have no effect until
server regen.
Once we've initialised pScrn->pScreen is filled in, so we can just set
the property directly.
v2: Removed pointless version check, deobfuscate math (Walter Harms)
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
For the dri2 backend, we depend on xfree86 already, so we can walk the
options for the screen looking for a vendor string from xorg.conf. For
the swrast backend we don't have that luxury, so just say mesa. This
extension isn't really meaningful on Windows or OSX yet (since libglvnd
isn't really functional there yet), so on those platforms we don't say
anything and return BadValue for the token from QueryServerString.
v2: Use xnf* allocators when parsing options (Eric and Emil)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
When the HW cursor is hidden (e.g. because xf86CursorResetCursor
triggers a switch from HW cursor to SW cursor), the driver isn't
notified of this for disabled CRTCs. If the HW cursor was shown when the
CRTC was disabled, it may still be displayed when the CRTC is enabled
again.
Prevent this by explicitly hiding the HW cursor again after setting a
mode if it's currently supposed to be hidden.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94560
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
There are no longer any loadable font modules (not that they ever did
much in the first place), so stop pretending they're a defined ABI
surface.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Was removed from the tree in:
commit f175cf45ae
Author: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed Feb 10 09:34:34 2016 +0100
vidmode: move to a separate library of its own
but not removed from the Makefile, which broke 'make dist'.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Setting crtc->transformPresent to FALSE was preventing the transform
from actually taking effect and putting RandR into a confused state.
Now that the RandR 1.2 cursor code handles transforms correctly, we can
allow them to properly take effect.
Reviewed-by: Keith Packard <keithp@keithp.com>
Add xf86CursorResetCursor, which allows switching between HW and SW
cursor depending on the current state.
Call it from xf86DisableUnusedFunctions, which is called after any CRTC
configuration change such as setting a mode or disabling a CRTC. This
makes sure that SW cursor is used e.g. while a transform is in use on
any CRTC or while there are active PRIME output slaves, and enables HW
cursor again once none of those conditions are true anymore.
Reviewed-by: Keith Packard <keithp@keithp.com>
We currently don't handle transforms for the HW cursor image, so return
FALSE to signal a software cursor must be used if a transform is in use
on any CRTC.
v2: Check crtc->transformPresent instead of crtc->transform_in_use. The
latter is TRUE for rotation as well, which we handle correctly.
Reviewed-by: Keith Packard <keithp@keithp.com>
This patch introduces a new flag ATTR_KEY for hotplugged input devices,
so we can better distinguish between real keyboards (i.e. devices with
udev property ID_INPUT_KEYBOARD="1") and other key input devices like
lid switches, power buttons, etc.
All supported hotplug backends (udev, hal, and wscons) will set both
flags ATTR_KEY and ATTR_KEYBOARD for real keyboards, but udev backend
will set ATTR_KEY, but not ATTR_KEYBOARD, for non-keyboard key input
devices (hal and wscons will set both flags in any case). With this
distinction, kdrive input hotplugging mechanism will be allowed to only
grab real keyboards, as other key input devices are currently not
supported.
In order to don't break current behaviour, this patch will replace all
ATTR_KEYBOARD occurrences with ATTR_KEY in hw/xfree86/common/xf86Xinput.c.
[ajax: Just add ATTR_KEY, don't re-number the other attributes]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Laércio de Sousa <laerciosousa@sme-mogidascruzes.sp.gov.br>
The API signature of the DIX xf86VidModeGetGammaRampSize() is now
identical to the xf86cmap's xf86GetGammaRampSize() and all it does is
actually call xf86GetGammaRampSize() so we can save one vfunc.
Remove uneeded xf86VidModeGetGammaRampSize() function.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The DIX already checks for VidModePrivateKey to get the vfunc, so
checking for this again in the DDX is redundant.
Remove the redundant function xf86VidModeAvailable() from the DDX.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
XVidMode extension might be useful to non hardware servers as well (e.g.
Xwayand) so that applications that rely on it (e.g. lot of older games)
can at least have read access to XVidMode.
But the implementation is very XFree86 centric, so the idea is to add
a bunch of vfunc that other non-XFree86 servers can hook up into to
provide a similar functionality.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87806
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
To avoid confusion as to what belongs on the DDX and what not.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
