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>

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>

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>

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>

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>

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

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>

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

Verbosity level 0 is "always print", just make it a normal message.
Signed-off-by: Adam Jackson <ajax@redhat.com>

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>

___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>

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/340Signed-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/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>

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/108355Suggested-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>

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

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.

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.

`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>

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>

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.

Found by coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Misplaced parenthesis caused us to compare the sizeof, not the readlink return
value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Fixes: xorg/driver/xf86-video-fbdev#9Signed-off-by: Adam Jackson <ajax@redhat.com>

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>

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>

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.