-
051a0efc
by Peter Hutterer
at 2018-10-04T15:23:48Z
dix: check_modmap_change() returns Success, not true
Not sure what if anything calls XSetDeviceModifierMapping() but this would've
failed all the time. check_modmap_change() returns Success but we were
treating it like a boolean. Fix this.
Reported-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 4fe02b8da3ca58500f7e6e017e388907cf4a8b73)
-
5396a4aa
by Alex Goins
at 2018-10-04T15:23:57Z
randr: rrCheckPixmapBounding should only increase screen size
The purpose of rrCheckPixmapBounding() is to make sure that the fb is large
enough to accommodate the region scanned out by a GPU screen. Currently, however,
it will actually shrink the fb if it's larger than it needs to be.
This is a problem when combining PRIME output slaving with arbitrary transforms
with xrandr.
Although arbitrary transforms are not supposed to constrain the size of the fb
(https://lists.freedesktop.org/archives/xorg-devel/2018-January/055563.html),
xrandr will use RRSetScreenSize to resize the desktop to accommodate scaling
transforms, e.g. scaling a 1920x1080 display to 3840x2160 will result in a
desktop size of 3840x2160.
In the case of PRIME, rrCheckPixmapBounding() will be called after
RRSetScreenSize() and it will resize the fb back down to what it would be
without the scaling transform, e.g. 1920x1080. This represents divergence in
behavior between PRIME and non-PRIME outputs.
I had originally made rrCheckPixmapBounding() account for arbitrary transforms,
but realized that the fb being large enough to accommodate arbitrary transforms
is not a hard requirement enforced in the server. Instead, this change simply
makes it so that rrCheckPixmapBounding() will only resize the fb to be larger
than it already is, preventing it from stepping on prior requests to increase
the size of the fb.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit a90f33721eba7f2dbde4a7278f1a213d696c85e9)
-
cd19a752
by Jim Qu
at 2018-10-04T15:24:42Z
modesetting: code refactor for PRIME sync
The X will be crashed on the system with other DDX driver,
such as amdgpu.
show the log like:
randr: falling back to unsynchronized pixmap sharing
(EE)
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e)
(EE) 1: /usr/lib/xorg/Xorg (0x55cb0151a000+0x1b5ce9)
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1587a1d000+0x11390)
(EE)
(EE) Segmentation fault at address 0x0
(EE)
The issue is that modesetting as the master, and amdgpu as the slave.
Thus, when the master attempts to access pSlavePixPriv in ms_dirty_update(),
problems result due to the fact that it's accessing AMD's 'ppriv' using the
modesetting structure definition.
Apart from fixing crash issue, the patch fix other issue in master interface
in which driver should refer to master pixmap.
Signed-off-by: Jim Qu <Jim.Qu@amd.com>
Reviewed-by: Alex Goins <agoins@nvidia.com>
(cherry picked from commit f79e5368512b72bb463925983d265b070261b7aa)
-
48300a77
by Scott Anderson
at 2018-10-04T15:24:50Z
xwayland: use wayland axis_discrete event
This prevents multiple scroll events happening for wayland compositors
which send axis values other than 10. For example, libinput will
typically return 15 for each scroll wheel step, and if a wayland
compositor sends those to xwayland without normalising them, 2 scroll
wheel steps will end up as 3 xorg scroll events. By listening for the
discrete_axis event, this will now correctly send only 2 xorg scroll
events.
The wayland protocol gurantees that there will always be an axis event
following an axis_discrete event. However, it does not gurantee that
other events (including other axis_discrete+axis pairs) will not happen
in between them. So we must keep a list of outstanding axis_discrete
events.
Signed-off-by: Scott Anderson <scott@anderso.nz>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit cd285922cdec966825e47220b1182a57abc1ff90)
-
1b0db2c7
by Lionel Landwerlin
at 2018-10-04T15:25:02Z
present: fix freed pointer access
When a vblank has been marked as aborted, it's going to be free in the
flip_notify function when stopped. We can't notify it after it's
stopped because the pointer is invalid.
Valgrind backtrace:
==5331== Invalid read of size 8
==5331== at 0x212B4D: present_vblank_notify (present_vblank.c:34)
==5331== by 0x21439B: present_wnmd_flip_notify (present_wnmd.c:194)
==5331== by 0x21439B: present_wnmd_event_notify (present_wnmd.c:228)
==5331== by 0x156216: xwl_present_sync_callback (xwayland-present.c:282)
==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== Address 0x1b44dc98 is 40 bytes inside a block of size 184 free'd
==5331== at 0x48369EB: free (vg_replace_malloc.c:530)
==5331== by 0x213B0A: present_wnmd_free_idle_vblanks (present_wnmd.c:118)
==5331== by 0x213B0A: present_wnmd_flips_stop (present_wnmd.c:161)
==5331== by 0x2143EF: present_wnmd_flip_notify (present_wnmd.c:192)
==5331== by 0x2143EF: present_wnmd_event_notify (present_wnmd.c:228)
==5331== by 0x156216: xwl_present_sync_callback (xwayland-present.c:282)
==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== Block was alloc'd at
==5331== at 0x48377D5: calloc (vg_replace_malloc.c:711)
==5331== by 0x212D9F: present_vblank_create (present_vblank.c:69)
==5331== by 0x214014: present_wnmd_pixmap (present_wnmd.c:610)
==5331== by 0x21576C: proc_present_pixmap (present_request.c:150)
==5331== by 0x27599D: Dispatch (dispatch.c:479)
==5331== by 0x279945: dix_main (main.c:276)
==5331== by 0x633AB16: (below main) (libc-start.c:310)
v2: Still notify aborted flips (Roman)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107314
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit ce271535adb6974e0a43bb64c8ed7a5dcaff67a2)
-
1191b23f
by Olivier Fourdan
at 2018-10-04T15:25:13Z
glx: check for indirect context in CreateContextAttribsARB()
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>
(cherry picked from commit 75448671abe2c6ae3745eb5d2ed2e76df2de9c41)
-
8dd7173e
by Lionel Landwerlin
at 2018-10-04T15:25:19Z
xwayland: fix access to invalid pointer
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>
(cherry picked from commit 53ce2ba0a19af9c549f47a4cc678afcebeb6087e)
-
cffac815
by Olivier Fourdan
at 2018-10-04T15:25:24Z
xwayland: Remove xwl_present_window from privates on cleanup
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>
(cherry picked from commit 3f31f56929e80001970e3821ed8b10c6075df8e6)
-
fdb80a32
by Adam Jackson
at 2018-10-04T15:25:30Z
modesetting: Lie less in the man page
We don't support 8bpp, and we do have acceleration.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 0dc2c419e11cf28b8fa1e607d4cf2d15f2eb2306)
-
8e646ca9
by Adam Jackson
at 2018-10-04T15:25:52Z
modesetting: Document Option "DoubleShadow" in the man page
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit c4f3e42fe316c90a73908a838ce64abbb28fe0a2)
-
bdeab786
by Dave Airlie
at 2018-10-04T15:25:59Z
shm: move shmsize verify before allocating the drawable.
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>
(cherry picked from commit 3439929c510501929c6ef1d90477c33bf8838632)
-
26a83f98
by Dave Airlie
at 2018-10-04T15:26:04Z
xi: free modifiers_failed on error path. (v2)
Pointed out by coverity.
v2: set modifies_failed to NULL at start (whot)
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 51ae6126dcf3e234d0f678f02934bc9515abb8ae)
-
bb384d0b
by Dave Airlie
at 2018-10-04T15:26:09Z
fboverlay: move bpp checks above malloc
Avoids having to free the malloced object.
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit c7fa6a0a0d4ad28ee21b8dd9ad4fbe33f462bc71)
-
795c58a1
by Dave Airlie
at 2018-10-04T15:26:15Z
glamor: fix leak of fs_getcolor_source.
This is created using XNFstrdup, so it needs to be freed.
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit f0a5c0d1fdaeee3cd701215f4f57b7eacaf783c2)
-
66d36010
by Dave Airlie
at 2018-10-04T15:26:20Z
modesetting: get pEnt after error checks
This saves us having to make sure we clean it up.
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit b6c29a881eb49300fddfd0187cb10891f5257d3b)
-
83ef0283
by Dave Airlie
at 2018-10-04T15:26:26Z
posix_tty: free leak of xf86SetStrOption return value.
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit cad3a1a82da3c8421b5cc98af27a779a38b5c709)
-
fcbdb7c8
by Dave Airlie
at 2018-10-04T15:26:44Z
xkb: fix what looks to be a copy-paste error with first vs firstMM
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 758393951233d1b2520cf4cefd33ec4288a3880a)
-
64a7aac2
by Dave Airlie
at 2018-10-04T15:26:51Z
mibltblt: free prgnSrcClip on error path.
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit c4591ea17110b5c318a5ef4b0f17a4eea306ea71)
-
cc4051ad
by Dave Airlie
at 2018-10-04T15:26:57Z
devices: break after finding and removing device from lists
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>
(cherry picked from commit ba0f5d854f4db52974ab5cd09191303b01b075ff)
-
fb01b238
by Adam Jackson
at 2018-10-04T15:27:03Z
xfree86: Fix Option "MaxClients" validation
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>
(cherry picked from commit 7d689f049c3cc16b8e0cb0103a384a2ceb84ea33)
-
c26a47b4
by Olivier Fourdan
at 2018-10-04T15:27:08Z
xwayland: Use `double` for `xwl_tablet_tool`
So we do not lose subpixel precision in Xwayland.
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/libinput/libinput/issues/138
(cherry picked from commit 734b2d6907f730571a2805cbc53fe7056190f19e)
-
94033359
by Cedric Roux
at 2018-10-04T15:27:15Z
miext/damage: take care of the coordinate mode in damagePolyPoint
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>
(cherry picked from commit bc36594e0eb8bfa5a673bcfd8c8168f70994a1df)
-
a41b6ef2
by Adam Jackson
at 2018-10-05T07:14:18Z
modesetting: Don't free(dst) in drmmode_prop_info_copy
The destination is always either on the stack or in the middle of some
struct.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 43a0f9a5dbb469f4f403a8530f33be67618933b8)
-
b1215fb0
by Pierre Ossman
at 2018-10-05T07:14:18Z
Switch automatic composite update to WorkQueue
It is currently (ab)using the screen BlockHandler callback to do
this. But this can cause problems with other extension as their
block handlers might have executed before Composite's. And the
operations Composite does might result in them wanting to change
timeouts.
Practically this caused problems for TigerVNC's VNC extension which
failed to send out updates for Composite's screen updates.
(cherry picked from commit 1bd5d0a53c5ff4169c5a6704c1c4b276f998b938)
-
b58aa8ed
by Alexander Volkov
at 2018-10-05T07:14:18Z
os/xdmcp: Don't create a new socket in XdmcpReset()
xdmcpSocket survives during the reset, there is no
need to create a new one.
This commit restores logic that was broken by
49c0f2413d32fdfe36e45861fcb32aaeab633094 in Xorg 1.19.
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
(cherry picked from commit 32677ce03d793a1f2aa8871112eb3d19b3cb762f)
-
1e3c5d61
by Adam Jackson
at 2018-10-12T15:35:00Z
glamor_egl: Don't initialize on llvmpipe
Mesa started supporting GL_OES_EGL_image on llvmpipe in 17.3, after this
commit:
commit bbdeddd5fd0b797e1e281f058338b3da4d98029d
Author: Gurchetan Singh <gurchetansingh@chromium.org>
Date: Tue Aug 1 14:49:33 2017 -0700
st/dri: add drisw image extension
That's pretty cool, but it means glamor now thinks it can initialize on
llvmpipe. This is almost certainly not what anyone wants, as glamor on
llvmpipe is pretty much uniformly slower than fb.
This fixes both Xorg and Xwayland to refuse glamor in such a setup.
Xephyr is left alone, both because glamor is not the default there and
because Xephyr+glamor+llvmpipe is one of the easier ways to get xts to
exercise glamor.
The (very small) downside of this change is that you lose DRI3 support.
This wouldn't have helped you very much (since an lp glamor blit is
slower than a pixman blit), but it would eliminate the PutImage overhead
for llvmpipe's glXSwapBuffers. A future change should add DRI3 support
for the fb-only case.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 0a9415cf793babed1f28c61f8047d51de04f1528)
-
4795c069
by Adam Jackson
at 2018-10-12T15:35:07Z
glamor/egl: Avoid crashing on broken configurations
0a9415cf apparently can tickle bugs in the GL stack where glGetString
returns NULL, presumably because the eglMakeCurrent() didn't manage to
actually install a dispatch table and you're hitting a stub function.
That's clearly not our bug, but if it happens we should at least not
crash. Notice this case and fail gently.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit af151895f3cb1755a7a5631f2398a3d3b219cbef)
-
f5dc787f
by Adam Jackson
at 2018-10-12T15:35:42Z
fbdevhw: Refuse to touch PCI devices on the fallback probe path
Fixes: https://gitlab.freedesktop.org/xorg/driver/xf86-video-fbdev/issues/9
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit fc78bcca21e767697de6ad4d8e03b6728856f613)
-
2a0c6c15
by Adam Jackson
at 2018-10-15T15:17:35Z
xserver 1.20.2
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
90c8d721
by Andreas Boll
at 2018-10-24T11:31:24Z
Merge tag 'xorg-server-1.20.2' into debian-unstable
xorg-server-1.20.2
-
17bb0f0f
by Andreas Boll
at 2018-10-24T11:32:23Z
Bump changelog
-
bb492a1e
by Andreas Boll
at 2018-10-24T11:53:51Z
Close some bugs
-
44caf375
by Andreas Boll
at 2018-10-24T11:58:22Z
Drop 08_dont-init-glamor-on-llvmpipe.diff, upstream.