Timo Aaltonen pushed to branch upstream-experimental at X Strike Force /
xserver / xorg-server
Commits:
0031bbad by Adam Jackson at 2018-04-12T17:15:15-04:00
sdksyms: Skip empty symbols
Apparently on NetBSD we can hit failures like this:
sdksyms.c:1773:15: error: expected expression before ',' token
(void *) &, /*
../../dri3/dri3.h:110 */
I've been unable to reproduce that locally (even in a NetBSD vm), but
an obvious workaround might be to just notice empty symbol names and
ignore them rather than emit invalid C code.
Tested-by: Thomas Klausner <w...@netbsd.org>
Signed-off-by: Adam Jackson <a...@redhat.com>
- - - - -
d7269b49 by Emil Velikov at 2018-04-12T17:17:43-04:00
configure.ac: make use of wayland-scanner.pc
Replace the current (incorrect) assumption that wayland-scanner is
located in the wayland-client prefix. Make use of the wayland_scanner
variable in wayland-scanner.pc
It was introduced back in 2013 and we already require newer wayland bits
Reviewed-by: Adam Jackson <a...@redhat.com>
Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
- - - - -
bf147f67 by Adam Jackson at 2018-04-13T10:49:56-04:00
xwayland: Don't crash on WarpPointer(dest_w = None)
Turns out that's legal, and xts exercises it, and we crash:
Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
dixGetPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20)
at ../../include/privates.h:122
122 return (char *) (*privates) + key->offset;
(gdb) bt
#0 dixGetPrivate (key=0x813660 <xwl_window_private_key>,
privates=0x20) at ../../include/privates.h:122
#1 dixLookupPrivate (key=0x813660 <xwl_window_private_key>,
privates=0x20) at ../../include/privates.h:166
#2 xwl_window_of_top (window=0x0) at xwayland.c:128
#3 xwl_cursor_warped_to (device=<optimized out>, screen=0x268b6e0,
client=<optimized out>, window=0x0, sprite=0x300bb30,
x=2400, y=1350) at xwayland.c:292
#4 0x00000000005622ec in ProcWarpPointer (client=0x32755d0) at
events.c:3618
In this case, x/y are the screen-space coordinates where the pointer
ends up, and we need to look up the (X) window there.
Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
- - - - -
c3ae963a by Olivier Fourdan at 2018-04-16T12:06:51-04:00
xwayland: Fix build without glamor
Present support in Xwayland relies on glamor, make sure Xwayland can
be built without glamor by moving references to Present code inside
the conditional GLAMOR_HAS_GBM.
Reported-by: Matt Turner <matts...@gmail.com>
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
Reviewed-by: Matt Turner <matts...@gmail.com>
Reviewed-by: Roman Gilg <subd...@gmail.com>
- - - - -
a98a95b7 by Matt Turner at 2018-04-16T14:10:58-04:00
modesetting: Move GBM code inside #ifdef GLAMOR_HAS_GBM
Fixes a compilation error without Glamor.
Bugzilla: https://bugs.gentoo.org/653288
Signed-off-by: Matt Turner <matts...@gmail.com>
Reviewed-by: Olivier Fourdan <ofour...@redhat.com>
- - - - -
4e92c51c by Mario Kleiner at 2018-04-17T10:24:42-04:00
dri3: Fix dri3_buffers_from_pixmap request.
Sending pixmap depth and bpp was omitted, so the Mesa
X11 + EGL + DRI3 side of things always failed to
dri3_create_image_khr_pixmap_from_buffers(), which led
to failure of X11 + EGL compositing under DRI3 under,
e.g., KDE Plasma 5.
Fixes: 6e7c40f62db6 ("dri3: Add multi-planar/modifier buffer
requests")
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Daniel Stone <dani...@collabora.com>
Cc: Louis-Francis Ratté-Boulianne <l...@collabora.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <l...@collabora.com>
Tested-by: Mike Lothian <m...@fireburn.co.uk>
- - - - -
78b6f940 by Adam Jackson at 2018-04-17T10:26:25-04:00
modesetting: Fix inverted check in dri2 WaitMSC
ms_queue_vblank() returns false on failure.
Reported-by: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-by: Frank Binns <frank.bi...@imgtec.com>
Tested-by: Mike Lothian <m...@fireburn.co.uk>
- - - - -
ac7a4bf4 by Chris Wilson at 2018-04-17T16:30:36-04:00
os/WaitFor: Check timers on every iteration
Currently we only check timer expiry if there are no client fd (or
other input) waiting to be serviced. This makes it very easy to starve
the timers with long request queues, and so miss critical timestamps.
The timer subsystem is just another input waiting to be serviced, so
evaluate it on every loop like all the others, at the cost of calling
GetTimeInMillis() slightly more frequently. (A more invasive and likely
OS specific alternative would be to move the timer wheel to the local
equivalent of timerfd, and treat it as an input fd to the event loop
exactly equivalent to all the others, and so also serviced on every
pass. The trade-off being that the kernel timer wheel is likely more
efficiently integrated with epoll, but individual updates to each timer
would then require syscalls.)
Reviewed-by: Peter Harris <phar...@opentext.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
- - - - -
12a6b189 by David Woodhouse at 2018-04-17T17:30:16-04:00
glamor: fix glamor_xv_query_image_attributes() for odd-width images
Images which are one pixel wider than a multiple of 8 are being handled
incorrectly. Other drivers round up the width to a multiple of two
before they start calculating. Do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=795235
Reviewed-by: Adam Jackson <a...@redhat.com>
Signed-off-by: David Woodhouse <dw...@infradead.org>
- - - - -
8b8f9007 by Olivier Fourdan at 2018-04-18T10:47:15-04:00
xwayland: avoid using freed xwl_window on unrealize
xwl_unrealize_window() would use freed xwl_window which can lead to
various memory corruption and crashes, as reported by valgrind:
Invalid read of size 8
at 0x42C802: xwl_present_cleanup (xwayland-present.c:84)
by 0x42BA67: xwl_unrealize_window (xwayland.c:601)
by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
by 0x57E1FA: UnrealizeTree (window.c:2816)
by 0x581189: UnmapWindow (window.c:2874)
by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
Address 0xf520f60 is 96 bytes inside a block of size 184 free'd
at 0x4C2EDAC: free (vg_replace_malloc.c:530)
by 0x42B9FB: xwl_unrealize_window (xwayland.c:624)
by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
by 0x57E1FA: UnrealizeTree (window.c:2816)
by 0x581189: UnmapWindow (window.c:2874)
by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
Block was alloc'd at
at 0x4C2FB06: calloc (vg_replace_malloc.c:711)
by 0x42B307: xwl_realize_window (xwayland.c:488)
by 0x541E59: compRealizeWindow (compwindow.c:268)
by 0x57DA40: RealizeTree (window.c:2617)
by 0x580B28: MapWindow (window.c:2694)
by 0x54EA2A: ProcMapWindow (dispatch.c:845)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
This is because UnrealizeTree() traverses the tree from top to bottom,
which invalidates the assumption that if the Window doesn't feature an
xwl_window on its own, it's the xwl_window of its first ancestor with
one.
This reverts commit 82df2ce3
Reviewed-by: Adam Jackson <a...@redhat.com>
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
- - - - -
3b4671f9 by Olivier Fourdan at 2018-04-19T16:15:44-04:00
xwayland: Clean up all frame callbacks
Regardless of the order we un-realize windows.
Suggested-by: Roman Gilg <subd...@gmail.com>
Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
Reviewed-by: Roman Gilg <subd...@gmail.com>
- - - - -
4e28a6a2 by Lyude Paul at 2018-04-19T16:20:22-04:00
meson: Ensure we always build Xext/hashtable.c for glx
Seems that while glxvnd relies on some of the hashtable functions in
Xext, we only build hashtable support for Xext if we're also building
the res extension. This leads to some errors if you try to build glx
without res enabled:
glx/liblibglxvnd.a(vndcmds.c.o): In function `LookupVendorPrivDispatch':
/home/lyudess/Projects/xserver/glx/vndcmds.c:65: undefined reference to
`ht_find'
/home/lyudess/Projects/xserver/glx/vndcmds.c:67: undefined reference to
`ht_add'
glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchInit':
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to
`ht_generic_compare'
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to
`ht_generic_hash'
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to
`ht_create'
glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchReset':
/home/lyudess/Projects/xserver/glx/vndcmds.c:468: undefined reference to
`ht_destroy'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
So, make sure that hashtable.c gets both for both glx and res
Reviewed-by: Adam Jackson <a...@redhat.com>
Signed-off-by: Lyude Paul <ly...@redhat.com>
- - - - -
fe4d1876 by Lyude Paul at 2018-04-19T16:20:27-04:00
meson: Fix indenting in glx/meson.build
No functional changes, just fixing a tabs vs. space error I noticed
Signed-off-by: Lyude Paul <ly...@redhat.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
- - - - -
e29d7832 by Mario Kleiner at 2018-04-23T14:05:43-04:00
modesetting: Only use modifiers on kms drivers which do support them.
Use the DRM_CAP_ADDFB2_MODIFIERS query to make sure the kms
driver supports modifiers in the addfb2 ioctl, and fall back
to addfb ioctl without modifiers if modifiers are unsupported.
E.g., as of Linux 4.17, nouveau-kms so far does not suppport
modifiers and gets angry if drmModeAddFB2WithModifiers() is
called (-> failure to set a video mode -> blank screen), but
Mesa's nvc0+ gallium driver causes gbm_bo_get_modifier() to
return a valid modifier by translating the default tiling of
bo's created via gbm_bo_create() into a modifier other than
DRM_FORMAT_MOD_INVALID (see Mesa's nvc0_miptree_get_modifier()).
Testing for != DRM_FORMAT_MOD_INVALID is apparently not
sufficient for safe use of drmModeAddFB2WithModifiers.
Bonus: Handle potential failure of populate_format_modifiers().
The required DRM_CAP is defined since libdrm v2.4.65, and we
require v2.4.89+ for the server, so we can use it unconditionally.
Tested on intel-kms, radeon-kms, nouveau-kms. Fixes failure on
NVidia Pascal.
Fixes: 2f807c2324b4 ("modesetting: Add support for multi-plane pixmaps
when page-flipping")
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Daniel Stone <dani...@collabora.com>
Cc: Louis-Francis Ratté-Boulianne <l...@collabora.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <l...@collabora.com>
- - - - -
82759039 by Thomas Klausner at 2018-04-23T14:56:17-04:00
sdksyms: Cope with __pid_t and __uint32_t
Kludge sdksyms.c generator to not fail on GetClientPid.
It returns pid_t which on NetBSD is #define pid_t __pid_t
This slightly alters the GCC preprocessor output which this fragile
code could not deal with when using GCC 5+
Signed-off-by: Adam Jackson <a...@redhat.com>
- - - - -
9d5af632 by Adam Jackson at 2018-04-24T14:28:27-04:00
animcur: Fix crash when removing a master device
Reproducer:
$ Xvfb -ac -noreset :1 &
$ DISPLAY=:1 xinput create-master touch1
$ DISPLAY=:1 xinput remove-master "touch1 pointer"
Bugzilla: https://bugs.freedesktop.org/105761
Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
- - - - -
73a1cb9c by Adam Jackson at 2018-04-24T14:36:03-04:00
dix: Factor out extension availability check
Signed-off-by: Adam Jackson <a...@redhat.com>
- - - - -
fc25bceb by Adam Jackson at 2018-04-24T14:36:04-04:00
dix: Allow an extension to disable itself
GLX registers an extension before we know if there are any screens that
can actually do it. It's inconvenient to shrink the extension list, so
instead allow the extension to simply zero out its base opcode to
indicate that it needed to panic and disable itself.
Signed-off-by: Adam Jackson <a...@redhat.com>
- - - - -
818885e6 by Adam Jackson at 2018-04-24T14:36:04-04:00
vnd: Disable GLX if no vendors successfully initialized
Signed-off-by: Adam Jackson <a...@redhat.com>
- - - - -
79a71375 by Adam Jackson at 2018-04-24T14:36:04-04:00
glx: Require depth > 12 for GLX visuals
fb is happy to do TrueColor to 8bpp drawables, but mesa is not. Depth 12
is the biggest pseudocolor anyone ever really did, and 15 is the least
truecolor.
Without this Xvfb at depth 8 would "have" GLX, but no vendors
would actually back any of the screens. libGL will attempt to call
GLXQueryServerString to figure out the GLX version, and vnd will throw
an error because there's no vendor to dispatch that to, and then clients
crash.
Signed-off-by: Adam Jackson <a...@redhat.com>
- - - - -
d2d664df by Adam Jackson at 2018-04-24T14:44:06-04:00
vfb: Fix man page in re depth
32 is not a valid depth, and the default is now 24 not 8.
Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersm...@oracle.com>
- - - - -
1545e2db by Lyude Paul at 2018-04-24T14:58:16-04:00
xwayland: Decouple GBM from glamor
This takes all of the gbm related code in wayland-glamor.c and moves it
into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
Additionally, we add the egl_backend struct into xwl_screen in order to
provide hooks for alternative EGL backends such as nvidia's EGLStreams.
Signed-off-by: Lyude Paul <ly...@redhat.com>
Reviewed-by: Lyude Paul <ly...@redhat.com>
Reviewed-by: Daniel Stone <dani...@collabora.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
- - - - -
994f7810 by Lyude Paul at 2018-04-24T14:58:19-04:00
xwayland: Add xwayland-config.h
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul <ly...@redhat.com>
Reviewed-by: Daniel Stone <dani...@collabora.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
- - - - -
54ac0971 by Lyude Paul at 2018-04-24T16:51:18-04:00
xwayland: Add glamor egl_backend for EGLStreams
This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.
EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.
This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps. no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:
- egl_backend.allow_commits for holding off displaying any EGLStream
backed pixmaps until the point where it's stream is completely
initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
surface producer before Xwayland actually damages and commits the
wl_surface to the screen.
The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.
Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).
While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul <ly...@redhat.com>
Acked-by: Daniel Stone <dani...@collabora.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
- - - - -
c593d843 by Daniel Stone at 2018-04-24T16:59:08-04:00
dri3: Don't call vfuncs on old DRI3 screens
Only call the get_supported_modifiers vfunc if the DRI3 screen struct is
sufficiently new.
Signed-off-by: Daniel Stone <dani...@collabora.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
- - - - -
c6ab2102 by Adam Jackson at 2018-04-24T17:03:07-04:00
xserver 1.20 RC5
Signed-off-by: Adam Jackson <a...@redhat.com>
- - - - -
30 changed files:
- Xext/meson.build
- configure.ac
- dix/extension.c
- dri3/dri3_request.c
- dri3/dri3_screen.c
- glamor/glamor_xv.c
- glx/glxext.c
- glx/meson.build
- glx/vndcmds.c
- glx/vndext.c
- glx/vndserver.h
- hw/vfb/man/Xvfb.man
- hw/xfree86/drivers/modesetting/dri2.c
- hw/xfree86/drivers/modesetting/driver.c
- hw/xfree86/drivers/modesetting/driver.h
- hw/xfree86/drivers/modesetting/drmmode_display.c
- hw/xfree86/sdksyms.sh
- hw/xwayland/Makefile.am
- hw/xwayland/meson.build
- + hw/xwayland/xwayland-glamor-eglstream.c
- + hw/xwayland/xwayland-glamor-gbm.c
- hw/xwayland/xwayland-glamor.c
- hw/xwayland/xwayland-input.c
- hw/xwayland/xwayland-present.c
- hw/xwayland/xwayland.c
- hw/xwayland/xwayland.h
- include/meson.build
- + include/xwayland-config.h.in
- + include/xwayland-config.h.meson.in
- meson.build
The diff was not included because it is too large.
View it on GitLab:
https://salsa.debian.org/xorg-team/xserver/xorg-server/compare/d61e516c847b9ff7e89e6be269050032070c1ad3...c6ab21022ce876f9c1409db4bb1967134f9f6dbe
---
View it on GitLab:
https://salsa.debian.org/xorg-team/xserver/xorg-server/compare/d61e516c847b9ff7e89e6be269050032070c1ad3...c6ab21022ce876f9c1409db4bb1967134f9f6dbe
You're receiving this email because of your account on salsa.debian.org.
