Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.
Fixes using GL with the modesetting driver for me.
Seems we were way behind on this one, time to look into something
more scalable?
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Copied from Mesa with no modifications.
Gives us Cofeelake platform names updates and sync on Kaby Lake,
Ice Lake PCI IDs.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Copied from Mesa with no modifications.
Gives us Geminilake and Kaby Lake platform names updates and
sync on Coffee Lake PCI IDs.
Cc: Timo Aaltonen <timo.aaltonen@canonical.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with
the ARRAY_SIZE macro from dix.h when possible. A semantic patch for
coccinelle has been used first. Additionally, a few macros have been
inlined as they had only one or two users.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Makes it easer to follow if 8 is between 7 and 9 ;-)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Copied from Mesa with no modifications.
Gives us Coffee Lake and Cannon Lake PCI IDs.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
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>
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>
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>
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>
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>
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>
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>
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>
This patch was motivated by the need to fix the use-after-free in
dri2ClientWake, but in doing so removes an arbitrary restriction that
limits DRI2 to only blocking the first client on each drawable. In order
to fix the use-after-free, we need to avoid touching our privates in the
ClientSleep callback and so we want to only use that external list as
our means of controlling sleeps and wakeups. We thus have a list of
sleeping clients at our disposal and can manage multiple events and
sources.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add virtio-gpu legacy + 1.0 pci ids, allowing them to use
modesetting + glamor with dri2.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
In commit e43abdce96
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Feb 3 09:54:46 2016 +0000
dri2: Unblock Clients on Drawable release
we try to wake up any blocked clients at drawable destruction. But by
the time we get there, CloseDownConnection has already torn down state
that AttendClient wants to modify.
Using ClientSleep instead of IgnoreClient puts a wakeup function on a
workqueue, and the queue will be cleared for us in CloseDownClient
before (non-neverretain) resource teardown.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If the Window is destroyed by another client, such as the window
manager, the original client may be blocked by DRI2 awaiting a vblank
event. When this happens, DRI2DrawableGone forgets to unblock that
client and so the wait never completes.
Note Present/xshmfence is also suspectible to this race.
Testcase: dri2-race/manager
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
All callers of SetWindowPixmap will themselves be traversing the Window
heirarchy updating the backing Pixmap of each child and so we can forgo
doing the identical traversal inside the DRI2SetWindowPixmap handler.
Reported-by: Loïc Yhuel <loic.yhuel@gmail.com>
Link: http://lists.x.org/archives/xorg-devel/2015-February/045638.html
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Adds Skylake, Kabylake and Broxton allowing them to use
modesetting + glamor with dri2.
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Reviewed-by: Andreas Boll <andreas.boll.dev@gmail.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>
Check for integer overflow before using stuff->count in a multiplication,
to avoid compiler optimizing out due to undefined behaviour, but only
after we've checked to make sure stuff->count is in the range of the
request we're parsing.
Reported-by: jes@posteo.de
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Currently when the ddx does not set any driver name we set DRI2 driver but
not the VDPAU driver name. The result is that VDPAU drivers will not get found
by libvdpau when the modesetting driver is being used.
Just assume that the VDPAU driver matches the DRI2 driver name, this is true
for nouveau, r300, r600 and radeonsi i.e all VDPAU drivers currently supported
by mesa.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
As a DDX may declare offload support without supporting DRI2
(because it is using an alternative acceleration mechanism like DRI3),
when iterating the list of offload_source Screens to find a matching
DRI2 provider we need to check before assuming it is DRI2 capable.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88514
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
ProcDRI2GetBuffers() tries to validate a length field (count).
There is an integer overflow in the validation. This can cause
out of bound reads and memory corruption later on.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Create hw/xfree86/dri2/pci_ids/Makefile.am which includes all of the new
pci id files in the tarballs. Build that from configure.ac, and run it
from dri2/Makefile.am
Signed-off-by: Keith Packard <keithp@keithp.com>
This will be used by the modesetting driver to support DRI2 across all
hardware that can support glamor, and could potentially be used by
other drivers that have to support DRI2 on sets of hardware with
multiple Mesa drivers.
This logic is the same as what's present in the Mesa driver loader,
except for the lack of nouveau_vieux support (which requires a
predicate on the device).
v2: Fix duplicated assignment of info->driverName.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This comes from Mesa commit acdcef6788beaa2a1532e13ff84c3e246b8025ed
Previously, each driver had to tell DRI2 what GL driver object should
be loaded. Originally for a 2D driver that was a matter of giving the
constant string for the vendor name, same as the driver's name. For a
driver that's trying to handle multiple generations of hardware with
different Mesa driver filenames, the driver had to bake in a mapping
from PCI ID to the appropriate driver name in Mesa, which seems like a
pretty awful layering violation (and one that was fixed with DRI3)
As of January, Mesa now handles the mapping from a DRI fd to the
driver name on its own, but the AIGLX loader still relies on DRI2 for
choosing the filename. Instead of propagating the PCI ID list from
each 2D driver to the modesetting driver, import a central copy of the
PCI ID list so that drivers can stop handling this themselves. (Some
day, when AIGLX transitions to EGL, we can drop the DRI2 filename
setup entirely).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When transitioning to a redirected or unredirected Window, the Composite
layer modifies the Window's Pixmap. However, the DRI2Buffer for the
Drawable is still pointing to the backing bo of the old Pixmap with the
result that rendering goes astray.
This now also effects DRI2 Drawables that are touched by PresentPixmap.
v2: Fixup the function name after rebasing
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Reinis Danne <reinis.danne@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This fixes a segfault when we attempt to call ds->ReuseBufferNotify()
passing a Prime DRI2BufferPtr to the master backend.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80001
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Checking the iterating variable ("slave") against null can not detect if the
xorg_list_for_each_entry finished without break being invoked - slave variable
will be always non-null. This caused segfault whenever someone tried to use
DRI_PRIME with incorrect id while having at least one render offloading slave
configured.
Restructurize the GetScreenPrime to work as expected.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes Piglit test "swapbuffersmsc-return swap_interval 0".
Ensure that *swap_target gets initialized on any 'return Success' path,
even if the swap request can't be completed by the driver and the server
falls back to a simple blit. That path can also be triggered by setting
swap_interval to 0, which disables sync to vertical retrace.
We originally found this bug because for some reason SDL2 automatically
sets swap_interval to 0, when we were trying to test OML_sync_control in
an SDL2 test application. We then discovered that the above-mentioned
Piglit test has been failing for the same reason since it was
introduced.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Theo Hill <Theo0x48@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
swap_target is an out-parameter that needs to be set to the value that
SBC will take on after this SwapBuffers request completes.
However, it was also being used as a temporary variable to hold the MSC
at which the SwapBuffers request got scheduled to occur. This confusion
makes it harder to reason about whether swap_target is being set
correctly for its out-parameter usage. (Hint: It isn't.)
For the latter use, it makes more sense to use the existing target_msc
variable, which already has the right value unless target_msc, divisor,
and remainder are all 0, in which case we can set it using swap_interval
as usual.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Theo Hill <Theo0x48@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This gets the easy warnings, mostly constant string problems.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Would only work on ScreenRec 0, which means it's broken.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This reverts commit 3209b094a3. After a
long debug session by Paul Berry, it appears that this was the commit
that has been producing sporadic failures in piglit front buffer
rendering tests for the last several years.
GetBuffers may return fresh buffers with invalid contents at a couple
reasonable times:
- When first asked for a non-fake-front buffer.
- When the drawable size is changed, an Invalidate has been sent, and
obviously the app needs to redraw the whole buffer.
- After a glXSwapBuffers(), GL allows the backbuffer to be undefined,
and an Invalidate was sent to tell the GL that it should grab these
appropriate new buffers to avoid stalling.
But with the patch being reverted, GetBuffers would also return fresh
invalid buffers when the drawable serial number changed, which is
approximately "whenever, for any reason". The app is not expecting
invalid buffer contents "whenever", nor is it valid. Because the GL
usually only GetBuffers after an Invalidate is sent, and the new
buffer allocation only happened during a GetBuffers, most apps saw no
problems. But apps that do (fake-)frontbuffer rendering do frequently
ask the server for the front buffer (since we drop the fake front
allocation when we're not doing front buffer rendering), and if the
drawable serial got bumped midway through a draw, the server would
pointlessly ditch the front *and* backbuffer full of important
drawing, resulting in bad rendering.
The patch was originally to fix bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=28365
Specifically:
To reproduce, start with a large-ish display (i.e. 1680x1050 on my
laptop), use the patched glxgears from bug 28252 to add the
-override option. Then run glxgears -override -geometry 640x480
to create a 640x480 window in the top left corner, which will work
fine. Next, run xrandr -s 640x480 and watch the fireworks.
I've tested with an override-redirect glxgears, both with vblank sync
enabled and disabled, both with gnome-shell and no window manager at
all, before and after this patch. The only problem observed was that
before and after the revert, sometimes when alt-tabbing to kill my
gears after completing the test gnome-shell would get confused about
override-redirectness of the glxgears window (according to a log
message) and apparently not bother doing any further compositing.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
After we share the pixmap, the backing storage may have changed,
and we need to invalidate and buffers pointing at it.
This fixes GL compositors and prime windows lacking contents initially.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These are two minor changes, one to reset the pointer to NULL,
after freeing the pixmaps, one to make sure we use the right API for
the master pixmap, though I doubt it'll ever really matter.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
When the drawable disappears we need to free the prime master/slave combos.
This fixes a leak after a prime app is run.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
DRI2GetParam was going through review in parallel with main batch of
C99 initialization changes - sync up now that both have landed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Same as DRI2CreateDrawable, except it can return the DRI2 specific XID of the
DRI2 drawable reference to the base drawable.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of keeping a tiny amount of code in an external module, just man
up and build it into the core server.
v2: Fix test/Makefile.am to only link libdri2.la if DRI2 is set
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
DRI2DestroyDrawable() was still being _X_EXPORTed, but hasn't existed
since 1da1f33f last year.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Rather than building the tiny amount of code required for XFree86-DRI as
an external module, build it in if it's enabled at configure time.
v2: Fix test/Makefile.am to only link libdri.la if DRI is set
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
fixup for DRI1 move
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Daniel Stone <daniel@fooishbar.org>