Use patched Xorg on all devices #1

dderby · 2018-04-20T02:08:03Z

No description provided.

MerlijnWajer · 2018-04-20T07:39:55Z

Look good to me. @parazyd ?

parazyd · 2018-04-20T07:50:25Z

This is also going to make the virtual machines use it. Is this fine?

EDIT
Nevermind, we can just build it for ARM. It slipped my mind :D

Xwayland would crash in some circumstances while trying to issue a pointer locking when the cursor is hidden when there is no seat focus window set. The crash signature looks like: #0 zwp_pointer_constraints_v1_lock_pointer () #1 xwl_pointer_warp_emulator_lock () at xwayland-input.c:2584 #2 xwl_seat_maybe_lock_on_hidden_cursor () at xwayland-input.c:2756 #3 xwl_seat_maybe_lock_on_hidden_cursor () at xwayland-input.c:2765 #4 xwl_seat_cursor_visibility_changed () at xwayland-input.c:2768 #5 xwl_set_cursor () at xwayland-cursor.c:245 #6 miPointerUpdateSprite () at mipointer.c:468 #7 miPointerDisplayCursor () at mipointer.c:206 #8 CursorDisplayCursor () at cursor.c:150 #9 AnimCurDisplayCursor () at animcur.c:220 #10 ChangeToCursor () at events.c:936 #11 ActivatePointerGrab () at events.c:1542 #12 GrabDevice () at events.c:5120 #13 ProcGrabPointer () at events.c:4908 #14 Dispatch () at dispatch.c:478 #15 dix_main () at main.c:276 xwl_pointer_warp_emulator_lock() tries to use the surface from the xwl_seat->focus_window leading to a NULL pointer dereference when that value is NULL. Check that xwl_seat->focus_window is not NULL earlier in the stack in xwl_seat_maybe_lock_on_hidden_cursor() and return early if not the case to avoid the crash. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=102474 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This is a rare occurrence of a crash in Xwayland for which I don't have the reproducing steps, just a core file. The backtrace looks as follow: #0 raise () from /usr/lib64/libc.so.6 #1 abort () from /usr/lib64/libc.so.6 #2 OsAbort () at utils.c:1361 #3 AbortServer () at log.c:877 #4 FatalError () at log.c:1015 #5 OsSigHandler () at osinit.c:154 #6 <signal handler called> #7 xwl_glamor_pixmap_get_wl_buffer () at xwayland-glamor.c:162 #8 xwl_screen_post_damage () at xwayland.c:514 #9 block_handler () at xwayland.c:665 #10 BlockHandler () at dixutils.c:388 #11 WaitForSomething () at WaitFor.c:219 #12 Dispatch () at dispatch.c:422 #13 dix_main () at main.c:287 The crash is caused by dereferencing “xwl_pixmap->buffer” in xwl_glamor_pixmap_get_wl_buffer() because “xwl_pixmap” is NULL. Reason for this is because the corresponding pixmap is from the root window and xwayland is rootless by default. This can happen if the window was mapped, redirected, damaged and unredirected immediately, before the damage is processed by Xwayland. Make sure to remove the dirty window from the damage list on unrealize to prevent this from happening. Credit goes to Adam Jackson <ajax@nwnk.net> and Daniel Stone <daniel@fooishbar.org> for finding the root cause the issue. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com>

Unfortunately, on my machine Xwayland immediately crashes when I try to start it. gdb backtrace: #0 0x00007ffff74f0e79 in wl_proxy_marshal () from target:/lib64/libwayland-client.so.0 #1 0x0000000000413172 in zwp_confined_pointer_v1_destroy (zwp_confined_pointer_v1=0x700000000) at hw/xwayland/Xwayland@exe/pointer-constraints-unstable-v1-client-protocol.h:612 #2 0x0000000000418bc0 in xwl_seat_destroy_confined_pointer (xwl_seat=0x8ba2a0) at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2839 #3 0x0000000000418c09 in xwl_seat_unconfine_pointer (xwl_seat=0x8ba2a0) at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2849 #4 0x0000000000410d97 in xwl_cursor_confined_to (device=0xa5a000, screen=0x8b9d80, window=0x9bdb70) at /home/lyudess/Projects/xserver/hw/xwayland/xwayland.c:328 #5 0x00000000004a8571 in ConfineCursorToWindow (pDev=0xa5a000, pWin=0x9bdb70, generateEvents=1, confineToScreen=0) at /home/lyudess/Projects/xserver/dix/events.c:900 #6 0x00000000004a94b7 in ScreenRestructured (pScreen=0x8b9d80) at /home/lyudess/Projects/xserver/dix/events.c:1387 #7 0x0000000000502386 in RRScreenSizeNotify (pScreen=0x8b9d80) at /home/lyudess/Projects/xserver/randr/rrscreen.c:160 #8 0x000000000041a83c in update_screen_size (xwl_output=0x8e7670, width=3840, height=2160) at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:203 #9 0x000000000041a9f0 in apply_output_change (xwl_output=0x8e7670) at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:252 #10 0x000000000041aaeb in xdg_output_handle_done (data=0x8e7670, xdg_output=0x8e7580) at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:307 #11 0x00007ffff50e9d1e in ffi_call_unix64 () at ../src/x86/unix64.S:76 #12 0x00007ffff50e968f in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>) at ../src/x86/ffi64.c:525 #13 0x00007ffff74f3d8b in wl_closure_invoke () from target:/lib64/libwayland-client.so.0 #14 0x00007ffff74f0928 in dispatch_event.isra () from target:/lib64/libwayland-client.so.0 #15 0x00007ffff74f1be4 in wl_display_dispatch_queue_pending () from target:/lib64/libwayland-client.so.0 #16 0x00007ffff74f200b in wl_display_roundtrip_queue () from target:/lib64/libwayland-client.so.0 #17 0x0000000000418cad in InitInput (argc=12, argv=0x7fffffffd9c8) at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2867 #18 0x00000000004a20e3 in dix_main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30) at /home/lyudess/Projects/xserver/dix/main.c:250 #19 0x0000000000420cb2 in main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30) at /home/lyudess/Projects/xserver/dix/stubmain.c:34 This appears to be the result of xwl_cursor_confined_to() and xwl_screen_get_default_seat(). While not against protocol, mutter ends up sending xdg_output before wl_seat. xwl_screen_get_default_seat() makes the naïve assumption that we always have a valid seat, we end up returning a pointer to the empty list itself instead of an actual seat and causing ourselves to segfault. So, actually return NULL in xwl_screen_get_default_seat() if the seat list is empty, and skip any pointer confinement processing in xwl_cursor_confined_to() when we don't have a seat setup yet. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com>

RRSetChanged (immediately above) was immune to screens with no master, but RRTellChanged was not: Thread 1 "X" received signal SIGSEGV, Segmentation fault. RRTellChanged (pScreen=<optimized out>) at ../../randr/randr.c:576 576 mastersp = rrGetScrPriv(master); (gdb) bt #0 RRTellChanged (pScreen=<optimized out>) at ../../randr/randr.c:576 #1 0x000055555566f1e9 in RRNoticePropertyChange (value=0x555555bfbf28, property=70, output=0x555555bfef10) at ../../randr/rrproperty.c:153 #2 RRChangeOutputProperty (output=output@entry=0x555555bfef10, property=<optimized out>, type=type@entry=19, format=format@entry=32, mode=<optimized out>, mode@entry=0, len=len@entry=1, value=0x7fffffffe77c, sendevent=1, pending=0) at ../../randr/rrproperty.c:263 #3 0x000055555566dba5 in RROutputSetNonDesktop (output=output@entry=0x555555bfef10, nonDesktop=nonDesktop@entry=0) at ../../randr/rroutput.c:333 ... Reported-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Adam Jackson <ajax@redhat.com>

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>

Xwayland will add and remove CRTCs as Wayland outputs are added or removed. If there is a pending flip when this occurs, the `xwl_present_sync_callback()` will be triggered after the Xwayland output's RRCtrcPtr has been destroyed, hence causing a crash in Xwayland while trying to use freed memory: #1 abort () #2 OsAbort () at utils.c:1350 #3 AbortServer () at log.c:877 #4 FatalError () at log.c:1015 #5 OsSigHandler () at osinit.c:156 #6 <signal handler called> #7 dixGetPrivate () at ../include/privates.h:122 #8 dixLookupPrivate () at ../include/privates.h:166 #9 present_screen_priv () at present_priv.h:198 #10 present_wnmd_flip () at present_wnmd.c:358 #11 present_wnmd_execute () at present_wnmd.c:466 #12 present_wnmd_re_execute () at present_wnmd.c:80 #13 xwl_present_sync_callback () at xwayland-present.c:287 #14 ffi_call_unix64 () from /lib64/libffi.so.6 #15 ffi_call () from /lib64/libffi.so.6 #16 wl_closure_invoke () at src/connection.c:1006 #17 dispatch_event () at src/wayland-client.c:1427 #18 dispatch_queue () at src/wayland-client.c:1573 #19 wl_display_dispatch_queue_pending () at src/wayland-client.c:1815 #20 wl_display_dispatch_pending () at src/wayland-client.c:1878 #21 xwl_read_events () at xwayland.c:814 #22 ospoll_wait () at ospoll.c:651 #23 WaitForSomething () at WaitFor.c:208 #24 Dispatch () at ../include/list.h:220 #25 dix_main () at main.c:276 To avoid the issue, get the `ScreenPtr` from the window instead of the CRTC that might have been just freed, `xwl_present_flip()` has no use for the CRTC anyway. Bugzilla: https://bugs.freedesktop.org/108249 Suggested-by: Michel Daenzer <michel.daenzer@amd.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Daenzer <michel.daenzer@amd.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit b768b7d6cec41b8b320c468ec41aab5a8b49b27b)

The function `xwl_glamor_gbm_create_pixmap()` first creates a buffer objects and then creates the xwl_pixmap from it. However, `xwl_glamor_gbm_create_pixmap_for_bo()` is not called if the buffer object creation fails, and `xwl_glamor_gbm_create_pixmap()` simply returns `glamor_create_pixmap()`. The problem with this is that if `xwl_glamor_gbm_create_pixmap_for_bo()` is not called then neither is `xwl_pixmap_set_private()` and further calls to `xwl_pixmap_get()` will return NULL and cause a NULL pointer dereference if the return value is not checked: #0 xwl_glamor_gbm_get_wl_buffer_for_pixmap () at hw/xwayland/xwayland-glamor-gbm.c:248 #1 xwl_window_post_damage () at hw/xwayland/xwayland.c:697 #2 xwl_display_post_damage () at hw/xwayland/xwayland.c:759 #3 block_handler () at hw/xwayland/xwayland.c:890 #4 BlockHandler () at dix/dixutils.c:388 #5 WaitForSomething () at os/WaitFor.c:201 #6 Dispatch () at dix/dispatch.c:421 #7 dix_main () at dix/main.c:276 #8 __libc_start_main () at ../csu/libc-start.c:308 #9 _start () (gdb) print xwl_pixmap $1 = (struct xwl_pixmap *) 0x0 Make sure we check for `xwl_pixmap_get()` returned value where relevant and fail gracefully if this is the case. See also: https://gitlab.gnome.org/GNOME/mutter/issues/340 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Marco Trevisan <mail@3v1n0.net> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 036794bebce72a3fa2f95996d2e537ff568e0ff1)

Xwayland creates and destroys the CRTC along with the Wayland outputs, so there is possibly a case where the number of CRTC drops to 0. However, `xwl_present_get_crtc()` always return `crtcs[0]` which is invalid when `numCrtcs` is 0. That leads to crash if a client queries the Present capabilities when there is no CRTC, the backtrace looks like: #0 raise() from libc.so #1 abort() from libc.so #2 OsAbort() at utils.c:1350 #3 AbortServer() at log.c:879 #4 FatalError() at log.c:1017 #5 OsSigHandler() at osinit.c:156 #6 OsSigHandler() at osinit.c:110 #7 <signal handler called> #8 main_arena() from libc.so #9 proc_present_query_capabilities() at present_request.c:236 #10 Dispatch() at dispatch.c:478 #11 dix_main() at main.c:276 To avoid returning an invalid pointer (`crtcs[0]`) in that case, simply check for `numCrtcs` being 0 and return `NULL` in that case. Thanks to Michel Dänzer <michel.daenzer@amd.com> for pointing this as a possible cause of the crash. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Bugzilla: https://bugzilla.redhat.com/1609181 (cherry picked from commit e8295c50209f2963fa2823e8de7e8363a38cd2d1)

On pointer enter notification, Xwayland checks for an existing pointer warp with a `NULL` sprite. In turn, `xwl_pointer_warp_emulator_maybe_lock()` checks for an existing grab and the destination window using `XYToWindow()` which does not check for the actual sprite not being `NULL`. So, in some cases, when the pointer enters the surface and there is an existing X11 grab which is not an ownerEvents grab, Xwayland would crash trying to dereference the `NULL` sprite pointer: #0 __GI_raise () #1 __GI_abort () at abort.c:79 #2 OsAbort () at utils.c:1351 #3 AbortServer () at log.c:879 #4 FatalError () at log.c:1017 #5 OsSigHandler () at osinit.c:156 #6 OsSigHandler () at osinit.c:110 #7 <signal handler called> #8 XYToWindow (pSprite=0x0, x=0, y=0) at events.c:2880 #9 xwl_pointer_warp_emulator_maybe_lock () at xwayland-input.c:2673 #10 pointer_handle_enter () at xwayland-input.c:434 Avoid the crash by simply checking for the sprite being not `NULL` in `xwl_pointer_warp_emulator_maybe_lock()` Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Bugzilla: https://bugzilla.redhat.com/1708119 (cherry picked from commit 0a07446318f248b65fcbc8ab8a73ead51153f09e)

If a client is in the process of being closed down, then its client->osPrivate pointer will be set to NULL by CloseDownConnection. This can cause a crash if freeing the client's resources results in a call to AttendClient. For example, if the client has a pending sync fence: Thread 1 "X" received signal SIGSEGV, Segmentation fault. AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942 (gdb) bt #0 AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942 #1 0x00005571c3dbb865 in SyncAwaitTriggerFired (pTrigger=<optimized out>) at ../Xext/sync.c:694 #2 0x00005571c3dd5749 in miSyncDestroyFence (pFence=0x5571c5063980) at ../miext/sync/misync.c:120 #3 0x00005571c3dbbc69 in FreeFence (obj=<optimized out>, id=<optimized out>) at ../Xext/sync.c:1909 #4 0x00005571c3d7a01d in doFreeResource (res=0x5571c506e3d0, skip=skip@entry=0) at ../dix/resource.c:880 #5 0x00005571c3d7b1dc in FreeClientResources (client=0x5571c4aed9a0) at ../dix/resource.c:1146 #6 FreeClientResources (client=0x5571c4aed9a0) at ../dix/resource.c:1109 #7 0x00005571c3d5525f in CloseDownClient (client=0x5571c4aed9a0) at ../dix/dispatch.c:3473 #8 0x00005571c3d55eeb in Dispatch () at ../dix/dispatch.c:492 #9 0x00005571c3d59e96 in dix_main (argc=3, argv=0x7ffe7854bc28, envp=<optimized out>) at ../dix/main.c:276 #10 0x00007fea4837cb6b in __libc_start_main (main=0x5571c3d1d060 <main>, argc=3, argv=0x7ffe7854bc28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe7854bc18) at ../csu/libc-start.c:308 #11 0x00005571c3d1d09a in _start () at ../Xext/sync.c:2378 (gdb) print client->osPrivate $1 = (void *) 0x0 Since the client is about to be freed, its ignore count doesn't matter and AttendClient can simply be a no-op. Check for client->clientGone in AttendClient and remove similar checks from two callers that had them. Signed-off-by: Aaron Plattner <aplattner@nvidia.com> (cherry picked from commit 4308f5d3d1fbd0f5dce81e22c0c3f08c65a7c9d8)

…ScrPriv Calling rrGetScrPriv when RandR isn't initialized causes an assertion failure that aborts the server: Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed. Thread 1 "Xorg" received signal SIGABRT, Aborted. 0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6 #1 0x00007ffff7892897 in abort () from /usr/lib/libc.so.6 #2 0x00007ffff7892767 in __assert_fail_base.cold () from /usr/lib/libc.so.6 #3 0x00007ffff78a1526 in __assert_fail () from /usr/lib/libc.so.6 #4 0x00007ffff7fb57c1 in dixGetPrivateAddr (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:121 #5 0x00007ffff7fb5822 in dixGetPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:136 #6 0x00007ffff7fb586a in dixLookupPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:166 #7 0x00007ffff7fb8445 in CreateScreenResources (pScreen=0x555555ab1790) at ../hw/xfree86/drivers/modesetting/driver.c:1335 #8 0x000055555576c5e4 in xf86CrtcCreateScreenResources (screen=0x555555ab1790) at ../hw/xfree86/modes/xf86Crtc.c:744 #9 0x00005555555d8bb6 in dix_main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/main.c:214 #10 0x00005555557a4f0b in main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/stubmain.c:34 This can happen, for example, if the server is configured with Xinerama and there is more than one X screen: Section "ServerLayout" Identifier "crash" Screen 0 "modesetting" Screen 1 "dummy" RightOf "modesetting" Option "Xinerama" EndSection Section "Device" Identifier "modesetting" Driver "modesetting" EndSection Section "Screen" Identifier "modesetting" Device "modesetting" EndSection Section "Device" Identifier "dummy" Driver "dummy" EndSection Section "Screen" Identifier "dummy" Device "dummy" EndSection The problem does not reproduce if there is only one X screen because of this code in xf86RandR12Init: #ifdef PANORAMIX /* XXX disable RandR when using Xinerama */ if (!noPanoramiXExtension) { if (xf86NumScreens == 1) noPanoramiXExtension = TRUE; else return TRUE; } #endif Fix the problem by checking dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv. This is similar to what the xf86-video-amdgpu driver does: https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/blob/fd66f5c0bea2b7c22a47bfd5eb1f22d32d166d9c/src/amdgpu_kms.c#L388 Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 4226c6d0329df440551b7b91ae573a82c64a1ac9)

A change during the 1.20 development cycle resulted in fbconfigs being walked and deallocated individually during __glXScreenDestroy. This change now avoids a use-after-free caused by that change. ==50859==ERROR: AddressSanitizer: heap-use-after-free on address 0x00010d3819c8 at pc 0x0001009d4230 bp 0x00016feca7a0 sp 0x00016feca798 READ of size 8 at 0x00010d3819c8 thread T5 #0 0x1009d422c in __glXScreenDestroy glxscreens.c:448 #1 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510 #2 0x1009d2734 in glxCloseScreen glxscreens.c:169 #3 0x100740a24 in dix_main main.c:325 #4 0x10023ed50 in server_thread quartzStartup.c:65 #5 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0) #6 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38) 0x00010d3819c8 is located 200 bytes inside of 12800-byte region [0x00010d381900,0x00010d384b00) freed by thread T5 here: #0 0x101477ba8 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fba8) #1 0x1009d4240 in __glXScreenDestroy glxscreens.c:449 #2 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510 #3 0x1009d2734 in glxCloseScreen glxscreens.c:169 #4 0x100740a24 in dix_main main.c:325 #5 0x10023ed50 in server_thread quartzStartup.c:65 #6 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0) #7 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38) previously allocated by thread T5 here: #0 0x101477e38 in wrap_calloc+0x9c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fe38) #1 0x100925a40 in __glXAquaCreateVisualConfigs visualConfigs.c:116 #2 0x10091cb24 in __glXAquaScreenProbe+0x224 (X11.bin:arm64+0x100730b24) #3 0x1009cd840 in xorgGlxServerInit glxext.c:528 #4 0x10074539c in _CallCallbacks dixutils.c:743 #5 0x100932a70 in CallCallbacks callback.h:83 #6 0x100932478 in GlxExtensionInit vndext.c:244 #7 0x10020a364 in InitExtensions miinitext.c:267 #8 0x10073fe7c in dix_main main.c:197 #9 0x10023ed50 in server_thread quartzStartup.c:65 #10 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0) #11 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38) Regressed-in: 4b0a3cb CC: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> (cherry picked from commit 487286d47260782d331229af10df17711cbca1ea)

Use patched Xorg on all devices

c180660

This was referenced Apr 20, 2018

N950 and N9 ports parazyd/arm-sdk#4

Merged

N950 and N9 initial ports maemo-leste/bugtracker#121

Closed

MerlijnWajer requested review from MerlijnWajer and parazyd April 20, 2018 07:39

parazyd merged commit 7726423 into maemo-leste-upstream-forks:maemo/ascii Apr 20, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use patched Xorg on all devices #1

Use patched Xorg on all devices #1

dderby commented Apr 20, 2018

MerlijnWajer commented Apr 20, 2018

parazyd commented Apr 20, 2018 •

edited

Loading

Use patched Xorg on all devices #1

Use patched Xorg on all devices #1

Conversation

dderby commented Apr 20, 2018

MerlijnWajer commented Apr 20, 2018

parazyd commented Apr 20, 2018 • edited Loading

parazyd commented Apr 20, 2018 •

edited

Loading