- Nov 13, 2018
-
-
The screensaver can regularly move its window to random offsets. It should use the ConfigureWindow function instead of calling the Screen's MoveWindow directly. Some MoveWindow implementations, such as compMoveWindow, rely on Screen's ConfigNotify being called first as it happens in ConfigureWindow. Reviewed-by: Adam Jackson <ajax@redhat.com>
-
Adam Jackson authored
This contortion made a bit more sense before we got SetNotifyFd and friends, but now there's no need for it. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Adam Jackson authored
I can't think of a good reason why this would need to be deferred to the work queue. When we get to this point we're never in the middle of request processing, so we can't corrupt the event/reply stream. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Adam Jackson authored
Again, as this is DDX state not screen state, run it from DDX setup not screen setup. Signed-off-by: Adam Jackson <ajax@redhat.com>
-
Adam Jackson authored
There are logically server state not screen state. Not that multiple screens works, at the moment, but that's no excuse to be sloppy. Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- Nov 12, 2018
-
-
-
When Retrieving touch delivery data we need to check if we have an active grab on such device, and in that case use it to delivery events. If we don't do this, when rejecting the touch events in DeactivatePointerGrab, we will end-up in creating an implicit grab that will change the device deviceGrab's state, causing a recursion during TouchEndTouch. Fixes #7 https://bugs.freedesktop.org/show_bug.cgi?id=96536
-
- Nov 10, 2018
-
-
Alan Coopersmith authored
They were defined as empty macros on all platforms except for the long unsupported Cray systems which needed to use bitfields to define types smaller than 64-bits. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
- Nov 06, 2018
-
-
This reverts commit b45c74f0. It broke the cursor in other games. Apparently those use cursor data with premultiplied alpha, but with some pixels having r/g/b values larger than the alpha value (which corresponds to original r/g/b values > 1.0), triggering the workaround. Seems the cure turned out worse than the disease, so revert. Bugzilla: https://bugs.freedesktop.org/108650
-
- Oct 31, 2018
-
-
Adam Jackson authored
Verbosity level 0 is "always print", just make it a normal message. Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- Oct 30, 2018
-
-
Adam Jackson authored
-
- Oct 29, 2018
-
-
Some Broadcom set-top-box boards have PCI busses, but the GPU is still probed through DT. We would dereference a null busid here in that case. Signed-off-by: Eric Anholt <eric@anholt.net>
-
- Oct 25, 2018
-
-
Adam Jackson authored
___CLIENTSIGNAL_DEFINED___ is a hack to work around the declaration of ClientSignal both in our own headers and in <X11/include/fontproto.h>, the latter of which is properly part of libXfont (1, only) but packaged in xorgproto because we have made some mistakes. ClientSignalAll needs no such workaround. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Anholt <eric@anholt.net>
-
Adam Jackson authored
Despite being packaged in xorgproto (formerly fontsproto), fontproto.h is actually a list of the ABI libXfont version 1 expected of the X server. We switched to libXfont2 three years ago, this is unnecessary. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Anholt <eric@anholt.net>
-
Completing them from xwl_present_sync_callback had at least two issues: * It was before the MSC was incremented in xwl_present_frame_callback, so the MSC value in the completion event could be lower than the target specified by the client. This could cause hangs with the Mesa Vulkan drivers. * It allowed clients to run at a frame-rate higher than the Wayland compositor's frame-rate, wasting energy on generating frames which were never displayed. This isn't expected to happen unless the client specified PresentOptionAsync (in which case flips are still completed from xwl_present_sync_callback, allowing higher frame-rates). v2: * Make xwl_present_has_events return true when there's a pending "synchronous" flip, so those complete after at most ~1 second even if the Wayland server doesn't send a frame event. Bugzilla: https://bugs.freedesktop.org/106713
-
And consolidate more code from xwl_present_timer_callback and xwl_present_frame_callback in it.
-
Apart from simplifying the code, this should also prevent a condition (which might only be possible with the following fix) reported in wayland/weston#115 (comment 52467): 1. xwl_present_timer_callback indirectly calls xwl_present_reset_timer -> xwl_present_free_timer 2. xwl_present_timer_callback then returns a non-0 value, so DoTimer calls TimerSet with the old xwl_present_window->frame_timer pointer which was freed in step 1 => use after free Calling xwl_present_reset_timer explicitly passes NULL to TimerSet if step 1 freed xwl_present_window->frame_timer, and it will allocate a new one.
-
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>
-
This has never been actually implemented, do not tempt people to use it. 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>
-
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>
-
Lifted from vfb. xfree86 had almost the same thing but unparameterized, port it to the vfb style. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
Turns out some apps (e.g. the Civilization VI game) use non-premultiplied cursor data which doesn't have any pixels with 0 alpha but non-0 non-alpha, but can still result in visual artifacts. This uses the method suggested by Kamil in https://bugs.freedesktop.org/92309#c19: check for pixels where any colour component value is larger than the alpha value, which isn't possible with premultiplied alpha. There can still be non-premultiplied data which won't be caught by this, but that should result in slightly incorrect colours and/or blending at the worst, not wildly incorrect colours such as shown in the bug report below. Bugzilla: https://bugs.freedesktop.org/108355 Suggested-by: Kamil Paral <kamil.paral@gmail.com>
-
CVE-2018-14665 also made it possible to exploit this to access memory. With -logfile forbidden when running with elevated privileges this is no longer an issue. Signed-off-by: Matthieu Herrb <matthieu@herrb.eu> Reviewed-by: Adam Jackson <ajax@redhat.com>
-
Could cause privilege elevation and/or arbitrary files overwrite, when the X server is running with elevated privileges (ie when Xorg is installed with the setuid bit set and started by a non-root user). CVE-2018-14665 Issue reported by Narendra Shinde and Red Hat. Signed-off-by: Matthieu Herrb <matthieu@herrb.eu> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Adam Jackson <ajax@redhat.com>
-
- Oct 24, 2018
-
-
Choose the socket fd of the correct address family based on the address family of the argument to the -from option. Fixes: xorg/xserver#4
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
xwl_present_window->sync_callback was leaked. The event memory was leaked if the corresponding buffer had already been released.
-
- Oct 23, 2018
-
-
Automatic compositing exists, if that's what you want then use it. Signed-off-by: Adam Jackson <ajax@redhat.com>
-
This allows X to run with glamor at these depths.
-
- Oct 18, 2018
-
-
`xwl_present_timer_callback()` is initially marked a private and later implemented as public. Let's keep that private, shall we. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
-
Adam Jackson authored
At the point where xf86BusProbe runs we haven't yet taken our own VT, which means we can't perform drm "master" operations on the device. This is tragic, because we need master to fish the bus id string out of the kernel, which we can only do after drmSetInterfaceVersion, which for some reason stores that string on the device not the file handle and thus needs master access. Fortunately we know the format of the busid string, and it happens to almost be the same as the ID_PATH variable from udev. Use that instead and stop calling drmSetInterfaceVersion. Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- Oct 16, 2018
-
-
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Dave Airlie <airlied@redhat.com>
-
If the X server is terminated while its VT is not active, it should not change the current VT. v2: Query current state in xf86CloseConsole using VT_GETSTATE instead of keeping track in xf86VTEnter/xf86VTLeave/etc.
-
Peter Hutterer authored
Found by coverity Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Oct 15, 2018
-
-
Peter Hutterer authored
Misplaced parenthesis caused us to compare the sizeof, not the readlink return value. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Oct 12, 2018
-
-
Fixes: xorg/driver/xf86-video-fbdev#9 Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- Oct 05, 2018
-
-
Adam Jackson authored
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>
-
- Oct 03, 2018
-
-
xdmcpSocket survives during the reset, there is no need to create a new one. This commit restores logic that was broken by 49c0f241 in Xorg 1.19. Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
-
Pierre Ossman (Work account) authored
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.
-