The extension came out in 2000, and all Mesa-supported hardware that
can do glamor supports it. We were already relying on the ARB version
being present on desktop.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This code is based on local patches which had been sitting in
FreeBSD and OpenBSD ports.
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
Signed-off-by: François Tigeot <ftigeot@wolfpond.org>
GetImage is allowed to return window border contents, so don't remove
that from the returned image.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Based on: https://patchwork.freedesktop.org/patch/85636/
Rewritten to just not walk the pointer.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Emi Velikov <emil.l.velikov@gmail.com>
Based on: https://patchwork.freedesktop.org/patch/85636/
Rewritten to also free the resources allocated by
panoramix_setup_ids().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Emi 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>
Useless as an XVideo implementation with zero adaptors might be, it's
apparently a thing in the wild. Catch this case and bail out of xv init
if it happens.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Prior to commit f95645c6f7 ("glx: Don't enable EXT_texture_from_pixmap
unconditionally") DRI glx would always advertise EXT_texture_from_pixmap.
That commit moved the setting of the extension in the extension bits from
__glXInitExtensionEnableBits to its callers so that
__glXInitExtensionEnableBits can be used more generally, but at the same
time made the setting of EXT_texture_from_pixmap conditionally on
__DRI_TEX_BUFFER being present.
This has result in an unintended behavior change which breaks e.g.
compositors running on llvmpipe. This commit makes the DRI swrast glx code
advertise EXT_texture_from_pixmap unconditionally again fixing this.
Fixes: f95645c6f7 ("glx: Don't enable EXT_texture_from_pixmap unconditionally")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Only add unconditional advertising of GLX_EXT_texture_from_pixmap
to glxdriswrast.c, do not also add it to glxdri2.c
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>
In Xwayland's xwl_unrealize_cursor(), the x_cursor is cleared up only
when a device value is provided to the UnrealizeCursor() routine, but
if the device is NULL as called from FreeCursor(), the corresponding
x_cursor for the xwl_seat is left untouched.
This might cause a segfault when trying to access the unrealized
cursor's devPrivates in xwl_seat_set_cursor().
A possible occurrence of this is the client changing the cursor, the
Xserver calling FreeCursor() which does UnrealizeCursor() and then
the Wayland server sending a pointer enter event, which invokes
xwl_seat_set_cursor() while the seat's x_cursor has just been
unrealized.
To avoid this, walk through all the xwl_seats and clear up all x_cursor
matching the cursor being unrealized.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
wl_display_flush() can fail with EAGAIN and Xwayland would make this a
fatal error.
When this happens, it means that Xwayland has flooded the Wayland file
descriptor, either because the Wayland compositor cannot cope or more
likely because of a deadlock situation where the Wayland compositor is
blocking, waiting for an X reply while Xwayland tries to write data to
the Wayland file descriptor.
The general consensus to avoid the deadlock is for the Wayland
compositor to never issue blocking X11 roundtrips, but in practice
blocking rountrips can occur in various places, including Xlib calls
themselves so this is not always achievable without major surgery in the
Wayland compositor/Window manager.
What this patch does is to avoid dispatching to the Wayland file
descriptor until it becomes available for writing again, while at the
same time continue processing X11 requests to release the deadlock.
This is not perfect, as there is still the possibility of another X
client hammering the connection and we'll still fail writing to the
Wayland connection eventually, but this improves things enough to avoid
a 100% repeatable crash with vlc and gtkperf.
Also, it is worth considering that window managers and Wayland
compositors such as mutter already have a higher priority than other
regular X clients thanks to XSyncSetPriority(), mitigating the risk.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1278159
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763400
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Keeping the shm fd open beyond pixmap creation means we can easily
reach the open file descriptor limit if an X client asks us to create
that many pixmaps. Instead, let's get the wl_buffer immediatly so that
we can destroy the shm pool and close the fd before being asked to
create more.
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
glUniform4ui is available starting in GL{,ES} 3.0. Technically it's
also in EXT_gpu_shader4, but that's not worth supporting. There was also
a MESA_shading_language_130 spec proposed at one point; if that ever
gets finished, we can update epoxy to know about it and fix up the
feature check.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Once I introduced a second X server being tested, I found that startx
hit races in choosing a display.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
I was confused by the behavior I'd written before. keithp and
mattst88 responded with shock that I would have made it so surprising,
as well.
v2: Point to index.html instead of problems.html, which won't exist if
we had no problems.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The "dmesg-fail" line was matching our "fail" regex, so if you didn't
have those we would ignore fails.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The normal xinit is racy because it doesn't use -displayfd. This
implements the bare minimum for testing purposes, using -displayfd to
sequence starting the client, and avoids adding yet another dependency
to the server.
v2: Fix asprintf error checks.
v3: Add error checking for fork(), clarify calloc() arg.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This speeds up headless testing of Xephyr -glamor with softpipe from
"a test per minute or so" to "a test every few seconds".
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Even if the pixmap's storage has alpha, it may have been uploaded with
garbage in the alpha channel, so we need to force the shader to set
alpha to 1. This was broken way back in
355334fcd9.
Fixes rendercheck -t composite -f x8r8g8b8.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The copy optimization in d37329cba4
replicated a bug from last time we did a copy optimization: CopyArea
is only defined for matching depths. This is only a problem at 15 vs
16 depth right now (24 vs 32 would also have matching Render formats,
but they should work) but be strict in case we store other depths
differently in the future.
Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4
v2: Drop excessive src->depth == dst->depth check that snuck in.
v3: Switch back to src->depth == dst->depth
v4: Touch up commit message (s/bpp/depth).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This function is used by the modesetting driver to implement DRI2 and
shouldn't fail on systems that don't support DRI3.
v2: Drop stale commit message wording, fix compiler warning (by anholt)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
v2: Fix "orignal" too (review feedback by ajax, change by anholt)_
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
This code is safe. If the data race fails, the result is that we take the
lock and recheck.
==================
WARNING: ThreadSanitizer: data race (pid=31401)
Read of size 1 at 0x00010f5d2500 by thread T11:
#0 wait_for_mieq_init darwinEvents.c:102 (X11.bin+0x00010003155a)
#1 -[X11Application(Private) sendX11NSEvent:] X11Application.m:1330 (X11.bin+0x00010001d652)
#2 __28-[X11Application sendEvent:]_block_invoke X11Application.m:476 (X11.bin+0x00010001887f)
#3 __tsan::invoke_and_release_block(void*) <null>:144 (libclang_rt.tsan_osx_dynamic.dylib+0x00000005d97b)
#4 _dispatch_client_callout <null>:33 (libdispatch.dylib+0x0000000020ef)
Previous write of size 1 at 0x00010f5d2500 by thread T8:
[failed to restore the stack]
Location is global 'mieqInitialized' at 0x00010f5d2500 (X11.bin+0x000100599500)
Thread T11 (tid=4367138, running) created by thread T-1
[failed to restore the stack]
Thread T8 (tid=4367130, running) created by main thread at:
#0 pthread_create <null>:144 (libclang_rt.tsan_osx_dynamic.dylib+0x000000024490)
#1 create_thread quartzStartup.c:78 (X11.bin+0x000100039d2d)
#2 QuartzInitServer quartzStartup.c:95 (X11.bin+0x000100039b96)
#3 X11ApplicationMain X11Application.m:1238 (X11.bin+0x00010001cd54)
#4 X11ControllerMain X11Controller.m:984 (X11.bin+0x00010002a5b2)
#5 server_main quartzStartup.c:136 (X11.bin+0x000100039fbb)
#6 do_start_x11_server bundle-main.c:436 (X11.bin+0x000100002e25)
#7 _Xstart_x11_server mach_startupServer.c:189 (X11.bin+0x000100004e09)
#8 mach_startup_server mach_startupServer.c:399 (X11.bin+0x0001000056a4)
#9 mach_msg_server mach_msg.c:563 (libsystem_kernel.dylib+0x000000012186)
#10 start <null>:29 (libdyld.dylib+0x000000005254)
SUMMARY: ThreadSanitizer: data race darwinEvents.c:102 in wait_for_mieq_init
==================
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This allows us to remove darwinEvents_lock() and darwinEvents_unlock()
and remove the serverRunning hack from dix
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
AppKit handles crashes on app launch with their own dialog now, so we shouldn't need to do this ourselves.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
When a client is marked as write blocked, clear any old 'write ready'
bit in the osfds structure so that a new indication of write ready
(which is marked as edge trigggered) will trigger the callback.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Tested-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Tested-by: Matthieu Herrb <matthieu@herrb.eu>
When a client with pending output is ready (has request data pending),
FlushAllOutput will skip it to get all of the requests processed
before sending any queued output. That means FlushAllOutput is going
to return with some output pending to a client which isn't known to be
write blocked. And that means NewOutputPending needs to be set so that
FlushAllOutput will get called again to actually go flush this client.
It might be interesting to try just flushing the client to send any
queued data along the way. This patch just restores the server
behavior to what it was before the ospoll changes.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Tested-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Tested-by: Matthieu Herrb <matthieu@herrb.eu>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
RedirectKey() action had been broken by commit 2e6190.
A dropped check caused over-intense autorepeat of keysyms enriched
with the action.
Previous to this commit, the check wrapped the entire switch() block,
which was dropped with the move to a separate function.
Restore the checking.
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This function will be called when a pointer is grabbed non-root window
set as the 'confineTo'. This will enable the ddx to handle the
confinement their own way.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
