- Apr 24, 2018
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
Only call the get_supported_modifiers vfunc if the DRI3 screen struct is sufficiently new. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
-
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 <lyude@redhat.com> Acked-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
-
Just a small autogenerated header that will soon contain more then just one macro. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
-
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 <lyude@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
-
Adam Jackson authored
32 is not a valid depth, and the default is now 24 not 8. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
Adam Jackson authored
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 <ajax@redhat.com>
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
Adam Jackson authored
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 <ajax@redhat.com>
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
Adam Jackson authored
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 <ajax@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 23, 2018
-
-
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 <ajax@redhat.com>
-
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: 2f807c23 ("modesetting: Add support for multi-plane pixmaps when page-flipping") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
-
- Apr 19, 2018
-
-
No functional changes, just fixing a tabs vs. space error I noticed Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
-
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 <ajax@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com>
-
Regardless of the order we un-realize windows. Suggested-by: Roman Gilg <subdiff@gmail.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Roman Gilg <subdiff@gmail.com>
-
- Apr 18, 2018
-
-
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 <ajax@redhat.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
-
- Apr 17, 2018
-
-
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 <ajax@redhat.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
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 <pharris@opentext.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Adam Jackson authored
ms_queue_vblank() returns false on failure. Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Tested-by: Mike Lothian <mike@fireburn.co.uk>
-
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: 6e7c40f6 ("dri3: Add multi-planar/modifier buffer requests") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Tested-by: Mike Lothian <mike@fireburn.co.uk>
-
- Apr 16, 2018
-
-
Fixes a compilation error without Glamor. Bugzilla: https://bugs.gentoo.org/653288 Signed-off-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
-
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 <mattst88@gmail.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Roman Gilg <subdiff@gmail.com>
-
- Apr 13, 2018
-
-
Adam Jackson authored
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 <ajax@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 12, 2018
-
-
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 <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Adam Jackson authored
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 <wiz@netbsd.org> Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- Apr 10, 2018
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
Cut down the unnecessary malloc/memcpy/free by utilising the explicit copy provided by the client. But above all: do so, after ensuring we get valid data from the implementation. Fixes: cef12efc ("glamor: Implement GetSupportedModifiers") Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
The caller may ignore the return value (will be addressed with later commit) so simply zero the count from the get-go. We're pretty much do so, in all cases but one :-\ Fixes: cef12efc ("glamor: Implement GetSupportedModifiers") Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
The caller may ignore the return value (will be addressed with later commit) so simply zero the count from the get-go. We're pretty much do so, in all cases but one :-\ Fixes: cef12efc ("glamor: Implement GetSupportedModifiers") Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Currently if the function fails, we'll fall into two false assumptions: - the the count is zero - that the storage pointer is safe for free() I've just fixed the former (in glamor + xwayland) and have no plans on adding yet another workaround for the latter. Simply zero both variables. Regardless if the implementation is missing the callback or it foobars with output variables (normally a bad idea). Bonus points - this fixes a bug where we feed garbage to free() further down ;-) Fixes: cef12efc ("glamor: Implement GetSupportedModifiers") Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
The caller may ignore the return value (will be addressed with later commit) so simply zero the count from the get-go. We're pretty much do so, in all cases but one :-\ Fixes: cef12efc ("glamor: Implement GetSupportedModifiers") Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
The caller may ignore the return value (will be addressed with later commit) so simply zero the count from the get-go. We're pretty much do so, in all cases but one :-\ Fixes: cef12efc ("glamor: Implement GetSupportedModifiers") Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
It makes it perfectly clear that we should not be modifying them. Should help highlight issues like the one fixed with previous commit. Fixes: cef12efc ("glamor: Implement GetSupportedModifiers") Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
The glamor_pixmap_from_fds error path erroneously closes the fds. We don't own them, plus the caller closes them after the function in called. Fixes: cef12efc ("glamor: Implement GetSupportedModifiers") Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
dri3_screen_info is the user provide dispatch. Something that we do not and should not change. When using the _ptr typecast + const the compiler barfs at us (rightfully so), so use the _rec one. [Silence a new const mismatch warning too - ajax] Fixes: 56313829 ("dri3: Add DRI3 extension") Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
-
Focus events are useless when 'from' and 'to' are the same. But when this is the result of a (Un)GrabKeyboard request, we should always send them, including when the window manager had previously used XSetInputFocus to specify the focus on a window which happens to be now taking a grab. This is notably needed for window manager using XI to always get keyboard events even during grabs, so they can determine exactly when grabbing is active. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Do not forget to delete key and value of every item and the hashtable itself.
-
Otherwise X server crashes if GLX is enabled and Composite disabled. For example the compIsAlternateVisual function will try to lookup CompScreenPtr using the CompScreenPrivateKey, but that was never initialized if Composite is disabled. Fixes: f84e59a4. ("glx: Duplicate relevant fbconfigs for compositing visuals") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104993 Signed-off-by: Michal Srb <msrb@suse.com>
-