Inspired by the previous bug, build something we can use to write
damage testcases, including testing for the bug.
Signed-off-by: Eric Anholt <eric@anholt.net>
The mode (CoordModeOrigin or CoordModePrevious) was not taken into
account when computing the box. The result was a bad drawing of
points in some situations (on my hardware/software configuration,
calling XDrawString followed by XDrawPoints in the mode
CoordModePrevious).
Signed-off-by: Cedric Roux <sed@free.fr>
Signed-off-by: Eric Anholt <eric@anholt.net>
v2:
Fix a bogus warning about a missing pixelformat attribute issued for every
pixelformat when WGL_ARB_framebuffer_sRGB isn't available
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Future work: To properly support GLX_ARB_create_context in indirect mode, we
need to use wglCreateContextAttribsARB() rather than wglCreateContext(),
when attribs are provided, rather than just dropping attribs on the floor,
as we currently do.
That probably entails removing the deferred context creation and instead
using a temporary window, as direct WGL does.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
In glxWinSetPixelFormat() handle the case where wglChoosePixelFormatARB()
fails and fallback to ChoosePixelFormat()
It seems for some drivers, wglChoosePixelFormatARB() can fail when the
provided DC doesn't belong to the driver (e.g. it's a compatible DC for a
bitmap, so allow a fallback to ChoosePixelFormat() if it fails.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Exposing these pixelFormats is problematic: they are provided by the 'GDI
Generic' renderer, which doesn't support the same set of extensions as the
IGD providing the more capable pixelFormats.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Instead of fetching just the sdkdir variable of xorg-server using pkg-config,
simply get all of the CFLAGS. Aside from completeness, this helps builds in
sysroots as pkg-config knows what to do with --cflags but doesn't remap
arbitrary variables.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Prodding the builder's filesystem for tmp dirs doesn't necessarily
tell you anything about what the actual host's filesystem is going to
look like, so we should just try the dirs at runtime.
Signed-off-by: Eric Anholt <eric@anholt.net>
I don't think this is useful information to have in the log, and it's
a bunch of autotools and meson logic to produce it.
Signed-off-by: Eric Anholt <eric@anholt.net>
60ec8ead broke the autotools build:
sdksyms.o:(.data+0x58): undefined reference to `InitConnectionLimits'
sdksyms.o:(.data+0x2ec8): undefined reference to `xf86ServerName'
collect2: error: ld returned 1 exit status
Makefile:811: recipe for target 'Xorg' failed
Likewise 3a4d7c79 for InitConnectionLimits.
Signed-off-by: Adam Jackson <ajax@redhat.com>
If it's really this important we should just do it and not complain. We
never do it so it must not matter.
Signed-off-by: Adam Jackson <ajax@redhat.com>
I'm sure printing the address of function pointers in modules you'd
loaded might have made sense back when we rolled our own dlopen, but we
got better.
Signed-off-by: Adam Jackson <ajax@redhat.com>
This variable was no longer being read anywhere. MAXCLIENTS the macro is
the compile-time maximum limit, LIMITCLIENTS the macro is the default
limit, LimitClients the variable is the limit for the current server.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The old code would not in fact validate the option value, though it
might complain about it in the log. It also didn't let you set some
legal values that the -maxclients command line option would.
Signed-off-by: Adam Jackson <ajax@redhat.com>
DGAShutdown() walks every screen and attempts to reset the mode. That's
maybe a reasonable thing to do, although the explicit loop is certainly
a bad smell.
In ddxGiveUp it's called after we've torn down the vga arbiter - and in
fact most of the rest of screen state - which is... very very bad. The
other place it's called is from the Control-Alt-BackSpace handler, where
we don't even attempt to do vga arb setup, and where in any case we're
going to escape the main loop eventually anyway.
Move all that cleanup work inside DGACloseScreen. This means it happens
earlier in server teardown than previously, but not in a way you're ever
going to be upset about.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Coverity complains about a use after free in here after the
freeing, I can't follow the linked list so well, but whot
says the device can only be on one list once, so break should
fix it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise if the VERIFY_SHMSIZE macro fails we leak the drawables
we allocated earlier.
Noticed by coverity scan.
Signed-off-by: Dave Airlie <airlied@redhat.com>
../Xext/xselinux_ext.c: In function ‘SELinuxExtensionInit’:
../Xext/xselinux_ext.c:692:21: warning: variable ‘extEntry’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Adam Jackson <ajax@redhat.com>
Useful when video decoders only output NV12. Currently
glamor Xv only supports I420 and YV12.
Note that Intel's sna supports I420, YV12, YUY2, UYVY, NV12.
Test: xvinfo | grep NV12
Test: gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! xvimagesink
v2: Combine the two texture2Ds on u_sampler.
Signed-off-by: Julien Isorce <jisorce@oblong.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Allow to upload the CbCr plane of an NV12 image into a GL texture.
Signed-off-by: Julien Isorce <jisorce@oblong.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Xwayland's `xwl_destroy_window()` invokes `xwl_present_cleanup()`
before the common `DestroyWindow()`.
But then `DestroyWindow()` calls `present_destroy_window()` which will
possibly end up in `xwl_present_abort_vblank()` which will try to access
data that was previously freed by `xwl_present_cleanup()`:
Invalid read of size 8
at 0x434184: xwl_present_abort_vblank (xwayland-present.c:378)
by 0x53785B: present_wnmd_abort_vblank (present_wnmd.c:651)
by 0x53695A: present_free_window_vblank (present_screen.c:87)
by 0x53695A: present_destroy_window (present_screen.c:152)
by 0x42A90D: xwl_destroy_window (xwayland.c:653)
by 0x584298: compDestroyWindow (compwindow.c:613)
by 0x53CEE3: damageDestroyWindow (damage.c:1570)
by 0x4F1BB8: DbeDestroyWindow (dbe.c:1326)
by 0x46F7F6: FreeWindowResources (window.c:1031)
by 0x472847: DeleteWindow (window.c:1099)
by 0x46B54C: doFreeResource (resource.c:880)
by 0x46C706: FreeClientResources (resource.c:1146)
by 0x446ADE: CloseDownClient (dispatch.c:3473)
Address 0x182abde0 is 80 bytes inside a block of size 112 free'd
at 0x4C2FDAC: free (vg_replace_malloc.c:530)
by 0x42A937: xwl_destroy_window (xwayland.c:647)
by 0x584298: compDestroyWindow (compwindow.c:613)
by 0x53CEE3: damageDestroyWindow (damage.c:1570)
by 0x4F1BB8: DbeDestroyWindow (dbe.c:1326)
by 0x46F7F6: FreeWindowResources (window.c:1031)
by 0x472847: DeleteWindow (window.c:1099)
by 0x46B54C: doFreeResource (resource.c:880)
by 0x46C706: FreeClientResources (resource.c:1146)
by 0x446ADE: CloseDownClient (dispatch.c:3473)
by 0x446DA5: ProcKillClient (dispatch.c:3279)
by 0x4476AF: Dispatch (dispatch.c:479)
Block was alloc'd at
at 0x4C30B06: calloc (vg_replace_malloc.c:711)
by 0x433F46: xwl_present_window_get_priv (xwayland-present.c:54)
by 0x434228: xwl_present_get_crtc (xwayland-present.c:302)
by 0x539728: proc_present_query_capabilities (present_request.c:227)
by 0x4476AF: Dispatch (dispatch.c:479)
by 0x44B5B5: dix_main (main.c:276)
by 0x75F611A: (below main) (libc-start.c:308)
This is because `xwl_present_cleanup()` frees the memory but does not
remove it from the window's privates, and `xwl_present_abort_vblank()`
will still find it and hence try to access that freed memory...
Remove `xwl_present_window` from window's privates on cleanup so that no
other function can find and reuse that data once it's freed.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1616269
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
xwl_output->randr_crtc is used in the update_screen_size() function :
==5331== Invalid read of size 4
==5331== at 0x15263D: update_screen_size (xwayland-output.c:190)
==5331== by 0x152C48: xwl_output_remove (xwayland-output.c:413)
==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814)
==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651)
==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208)
==5331== by 0x27574B: Dispatch (dispatch.c:421)
==5331== by 0x279945: dix_main (main.c:276)
==5331== Address 0x1aacb5f4 is 36 bytes inside a block of size 154 free'd
==5331== at 0x48369EB: free (vg_replace_malloc.c:530)
==5331== by 0x1F8AE8: RROutputDestroyResource (rroutput.c:421)
==5331== by 0x29A2AC: doFreeResource (resource.c:880)
==5331== by 0x29AE5B: FreeResource (resource.c:910)
==5331== by 0x152BE0: xwl_output_remove (xwayland-output.c:408)
==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814)
==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651)
==5331== Block was alloc'd at
==5331== at 0x48357BF: malloc (vg_replace_malloc.c:299)
==5331== by 0x1F93E0: RROutputCreate (rroutput.c:83)
==5331== by 0x152A75: xwl_output_create (xwayland-output.c:361)
==5331== by 0x14BE59: registry_global (xwayland.c:764)
==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814)
==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651)
==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Commit 99f0365b "Add a command line argument for disabling indirect GLX"
added a test to check if indirect context are enabled in
`DoCreateContext()` but `__glXDisp_CreateContextAttribsARB()` doesn't
use `DoCreateContext()` and doesn't check if indirect context is
enabled.
As a result, clients can still manage to create indirect contexts using
`glXCreateContextAttribsARB()` even if indirect contexts are disabled,
which can possibly crash Xservers such as Xwayland or Xephyr when the
context is destroyed.
To avoid the issue, check for `enableIndirectGLX` in
`__glXDisp_CreateContextAttribsARB()` as well.
Fixes: 99f0365b "Add a command line argument for disabling indirect GLX"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107508
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>