- 13 Nov, 2018 5 commits
-
-
Michal Srb authored
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>
-
- 12 Nov, 2018 2 commits
-
-
Marco Trevisan authored
-
Marco Trevisan authored
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
-
- 10 Nov, 2018 1 commit
-
-
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>
-
- 06 Nov, 2018 1 commit
-
-
Michel Dänzer authored
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
-
- 31 Oct, 2018 1 commit
-
-
Adam Jackson authored
Verbosity level 0 is "always print", just make it a normal message. Signed-off-by:
Adam Jackson <ajax@redhat.com>
-
- 30 Oct, 2018 1 commit
-
-
Adam Jackson authored
-
- 29 Oct, 2018 1 commit
-
-
Eric Anholt authored
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>
-
- 25 Oct, 2018 12 commits
-
-
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>
-
Michel Dänzer authored
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
-
Michel Dänzer authored
And consolidate more code from xwl_present_timer_callback and xwl_present_frame_callback in it.
-
Michel Dänzer authored
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.
-
Olivier Fourdan authored
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/340Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Marco Trevisan <mail@3v1n0.net> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Olivier Fourdan authored
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>
-
Olivier Fourdan authored
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/108249Suggested-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>
-
Adam Jackson authored
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>
-
Michel Dänzer authored
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/108355Suggested-by:
Kamil Paral <kamil.paral@gmail.com>
-
Matthieu Herrb authored
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>
-
Matthieu Herrb authored
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>
-
- 24 Oct, 2018 3 commits
-
-
Andreas Fett authored
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>
-
Michel Dänzer authored
xwl_present_window->sync_callback was leaked. The event memory was leaked if the corresponding buffer had already been released.
-
- 23 Oct, 2018 2 commits
-
-
Adam Jackson authored
Automatic compositing exists, if that's what you want then use it. Signed-off-by:
Adam Jackson <ajax@redhat.com>
-
Michel Dänzer authored
This allows X to run with glamor at these depths.
-
- 18 Oct, 2018 2 commits
-
-
Olivier Fourdan authored
`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>
-
- 16 Oct, 2018 3 commits
-
-
rpm-build authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by:
Dave Airlie <airlied@redhat.com>
-
Michal Srb authored
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>
-
- 15 Oct, 2018 2 commits
-
-
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>
-
- 12 Oct, 2018 1 commit
-
-
Adam Jackson authored
Fixes: xorg/driver/xf86-video-fbdev#9Signed-off-by:
Adam Jackson <ajax@redhat.com>
-
- 05 Oct, 2018 1 commit
-
-
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>
-
- 03 Oct, 2018 2 commits
-
-
Alexander Volkov authored
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.
-