Problems:
- neverball vsync mode not 60fps
- stutter
- fps dependend on moving mouse

Add support for the presentation_time protocol when presenting Pixmaps. This
allows us to get precise timing information on when a Pixmap was displayed to
the user.

The output msc timers are aligned with the vblank time after receiving the
first presented event. This should allow a well behaving Wayland compositor to
display frames in an optimal manner.

Wayland compositors not impelmenting the presentation_time protocol can still
make use of optimized flips without copy like before but the flips won't be
synchronized with the refresh cycle and clients won't get the real time when
the Pixmap was displayed.

This replaces the current approach of presenting XWayland windows by returned
frame callbacks with an approach to present along the current maximal refresh
rate of all outputs the surface has entered.

On relevant changes to the outputs all current flips or queued events are
abandoned by XWayland and Present will take care of finishing up their
processing. Such changes are relatively rare though such that under normal
circumstances flips and presentations aligned with output refresh rates should
be possible. For that the Wayland compositor must make sure that the enter and
leave events are sent for all XWayland surfaces as Wayland protocol prescribes.

One current downside is that the output timers are not aligned with the actual
vblank of the hardware such that there might be an one frame deviation.
Aligning could be done with frame callbacks. But the Wayland compositor must
make sure in this case to send the callbacks at the same rate as the maximal
refresh rate of all entered outputs (or for longer periods suspend them).

To play it safe with current compositors ignore this downside for now and
for optimizing that alignment instead use the presentation-time protocol in the
future.

In window mode allow DDX to hand back all currently queued vblanks to
Present.

This means Present will take  care of processing all remaining currently
queued vblanks and the DDX must not try to return information for these
in any form afterwards.

On the other side the DDX may process incoming new vblanks as usual.

With the reworked window mode previous DDX have become non-functional.

Therefore it became pointless trying to retain backwards compatibility. Remove
the legacy ust/msc getter in the window mode info struct and reset the window
mode info version to one.

Instead of keeping a list of current presentations in Present these are moved
to the DDX.

The DDX can then report back individually for each vblank if it was presented or
skipped, and if the associated Pixmap is ready to be reused again.

To simplify the code additional API functions are introduced specific to these
actions.

This is an API-breaking change in regards to window mode. DDX written against
the previous version won't work anymore. It is assumed that there only exists
the XWayland DDX at the moment using the window mode such that this is not an
issue for the overall ecosystem.

Can be used afterwards in other contexts and improves code readability.

Make it more clear that the member represents an event. It is synthetical in
the sense that the hardware synchronization with the display rate comes from
the in-software msc-bump function.

The new crtc argument is unused for now.

A small helper function is introduced to reduce code duplication.

With fake vblanks in Present we can simplify the XWayland code such that
vblanks are ignored while the window is unrealized.

The xwl_present_window struct holds a pointer back to the xwl_window while the
window is realized and xwl_window has a list of all presenting child windows.
This will be used in the future to forward information.

The entry existed already but was never set. We can set it easily though when
the struct gets allocated. Do this now so we can make use of it in the future.

The variable name for the list link of events was too generic. Rename it from
list to event_link such that it can be easily identified and grepped for.

The names release_queue and event_list were ambiguous: in both are event-like
vblanks. In the release_queue can be flips that are already released but still
wait for the sync or frame callback. In the event_list are queued events
waiting for a later msc.

Therefore rename release_queue to presentation_list and event_list to
queue_list.

Make it more obvious when this function is called by having the destroy part
in the name. It is called when the window is destroyed.

On surface enter and leave events add and respectively remove windows to the
entered output.

This later allows to inform all entered windows about changes to the output.

The microsecond precise timer can be used in the future to simulate hardware
vblank events.

The timer is kept in sync with the output's refresh rate and allows to realign
it manually with arbitrary points in time.

This enables Present to ask a DDX for ust/msc values specific to a certain
crtc.

The window argument is kept to allow DDX to select the returned value not only
dependent on crtc queried but also window and to keep the API flexible in the
future.

Enable usage of fake vblanks in window mode. A fake vblank is created when the
DDX does not provide a crtc for the window.

Fake vblanks in window mode are displayed at 60Hz for now to allow maximum
flexibility in its usage. Optimizing battery usage can be done on DDX level.

Introduce new function TimerSetInMicros to specify timers with microsecond
precision.

For that to facilitate internally all timers are from now on calculated
in microseconds. Timers through TimerSet are driven in the same way and their
results translated back.

Michel Dänzer authored Jun 19, 2020 and Michel Dänzer committed Jun 25, 2020

These events aren't reachable after xwl_present_cleanup, so they're
leaked if we don't free them first.

This requires storing the pixmap pointer in struct xwl_present_window.
Luckily, the buffer pointer isn't used for anything, so just replace
that.

v2:
* Bump pixmap reference count in xwl_present_flip and drop it in
  xwl_present_free_event, fixes use-after-free in the latter due to the
  pixmap already being destroyed.

Reviewed-by: Dave Airlie <airlied@redhat.com>

Michel Dänzer authored Jun 19, 2020 and Michel Dänzer committed Jun 25, 2020

Minor cleanup, and will make the next change simpler. No functional
change intended.

Reviewed-by: Dave Airlie <airlied@redhat.com>

Michel Dänzer authored Jun 19, 2020 and Michel Dänzer committed Jun 25, 2020

When present_wnmd_clear_window_flip is done, present_destroy_window
frees struct present_window_priv, and the events in the flip queue
become unreachable. So if we don't free them first, they're leaked.

Also drop the call to present_wnmd_set_abort_flip, which just sets a
flag in struct present_window_priv and thus can't have any observable
effect after present_destroy_window.

Closes: xorg/xserver#1042


Reviewed-by: Dave Airlie <airlied@redhat.com>

Michel Dänzer authored Jun 19, 2020 and Michel Dänzer committed Jun 25, 2020

The comment was incorrect: Any reference held by the window (see
present_wnmd_execute) is in addition to the one in struct present_vblank
(see present_vblank_create). So if we don't drop the latter, the pixmap
will be leaked.

Reviewed-by: Dave Airlie <airlied@redhat.com>

Martin Weber authored Jun 19, 2020 and Michel Dänzer committed Jun 24, 2020

During a VT-Switch a raw pointer to the shared cursor object
is saved which is then freed (in case of low refcount) by a call to
xf86CursorSetCursor with argument pCurs = NullCursor.
This leads to a dangling pointer which can follow in a use after free.

This fix ensures that there is a shared handle saved for the VT-Switch cycle.

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

EDID1.4 replaced GTF Bit with Continuous or Non-Continuous Frequency Display.

Check the "Display Range Limits Descriptor" for GTF support.
If panel doesn't support GTF, then add gtf modes.

Otherwise X will only show the modes in "Detailed Timing Descriptor".

V2: Coding style changes.
V3: Coding style changes, remove unused variate.
V4: remove unused variate.

BugLink: https://gitlab.freedesktop.org/drm/intel/issues/313


Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>

Simon Ser authored Jun 02, 2020 and Michel Dänzer committed Jun 19, 2020

When the linux-dmabuf protocol is available, prefer it over the old
wl_drm protocol. Previously wl_drm was used when modifiers aren't
supported, however linux-dmabuf supports formats without modifiers too.
In this case, linux-dmabuf will send a DRM_FORMAT_MOD_INVALID modifier
for each supported format [1].

This allows compositors to better handle these buffers, getting a
DMA-BUF and implementing features like direct scan-out.

A similar logic has been implemented for EGL [2].

DRM_FORMAT_MOD_INVALID is now stored in the xwl_screen->formats list.
glamor_get_modifiers still returns FALSE with zero modifiers if the
only advertised modifier is DRM_FORMAT_MOD_INVALID.

[1]: wayland/wayland-protocols@fb9b2a87
[2]: mesa/mesa@c376865f



Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

Simon Ser authored Jun 02, 2020 and Michel Dänzer committed Jun 19, 2020

Previously, linux-dmabuf was used unconditionally if the buffer had a
modifier. However creating a linux-dmabuf buffer with a format/modifier
which hasn't been advertised will fail.

Change xwl_glamor_gbm_get_wl_buffer_for_pixmap to use linux-dmabuf when
the format/modifier has been advertised only.

Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: xorg/xserver#1035


Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

This flag should only be used when the caller intends to display the
buffer on a hardware plane. Xwayland isn't a DRM client, so it doesn't
make sense to use this flag.

This change will allow the driver to potentially use buffer parameters
that are more optimized.

Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

Without this the client library will flail around looking for a default
provider, probably one named "indirect", and that defeats the point of
having the EGL provider for direct context support in the first place.

This assumes that "mesa" will work, of course, and in general it should.
Mesa drivers will DTRT through the DRI3 setup path, and if our glamor is
atop something non-Mesa then you should fall back to llvmpipe like 1.20.
In the future it might be useful to differentiate the vendor here based
on whether glamor is using gbm or streams.

Fixes: xorg/xserver#1032

None of the current BSD is actually using this code.
(checked DragonFly 5.8.1, FreeBSD 11.2, NetBSD 9.0 and OpenBSD 6.7)

Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>

DragonFly and FreeBSD can use xf86-input-libinput with config/udev.

ld: error: undefined symbol: xf86PlatformDeviceProbe
>>> referenced by xf86platformBus.c
>>>               xf86platformBus.c.o:(xf86platformProbe) in archive hw/xfree86/common/libxorg_common.a

ld: error: undefined symbol: xf86PlatformDeviceCheckBusID
>>> referenced by xf86platformBus.c
>>>               xf86platformBus.c.o:(xf86platformProbeDev) in archive hw/xfree86/common/libxorg_common.a

ld: error: undefined symbol: xf86PlatformReprobeDevice
>>> referenced by xf86platformBus.c
>>>               xf86platformBus.c.o:(xf86platformVTProbe) in archive hw/xfree86/common/libxorg_common.a

ld: error: undefined symbol: NewGPUDeviceRequest
>>> referenced by udev.c
>>>               udev.c.o:(device_added) in archive config/liblibxserver_config.a

ld: error: undefined symbol: DeleteGPUDeviceRequest
>>> referenced by udev.c
>>>               udev.c.o:(device_removed) in archive config/liblibxserver_config.a

In file included from ../glx/glxdri2.c:35:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
 #include <drm.h>
          ^~~~~~~
In file included from ../glx/glxdriswrast.c:39:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
 #include <drm.h>
          ^~~~~~~

../os/xsha1.c:36:10: fatal error: 'sha1.h' file not found
 #include <sha1.h>
          ^~~~~~~~
../os/xsha1.c:45:5: error: implicit declaration of function 'SHA1Init' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    SHA1Init(ctx);
    ^
../os/xsha1.c:54:5: error: implicit declaration of function 'SHA1Update' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    SHA1Update(sha1_ctx, data, size);
    ^
../os/xsha1.c:63:5: error: implicit declaration of function 'SHA1Final' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    SHA1Final(result, sha1_ctx);
    ^

Olivier Fourdan authored May 05, 2020 and Olivier Fourdan committed May 20, 2020

Xwayland uses the device private to point to the `xwl_seat`.

Device may be removed at any time, including on suspend.

On resume, if the DIX code ends up calling a function that requires the
`xwl_seat` such as `xwl_set_cursor()` we may end up pointing at random
data.

Make sure the clear the device private data on removal so that we don't
try to use it and crash later.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
xorg/xserver#709

wayland/ci-templates was moved to freedesktop/ci-templates, everything
else stayed the same so the sha is still valid.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>

Drop GBM_BO_USE_SCANOUT from the GBM_BO_IMPORT_FD import, add
GBM_BO_USE_RENDERING to the GBM_BO_IMPORT_FD_MODIFIER import.

If the DMA-BUF cannot be scanned out, gbm_bo_import with
GBM_BO_USE_SCANOUT will fail. However Xwayland doesn't need to scan-out
the buffer and can work fine without scanout. Glamor only needs
GBM_BO_USE_RENDERING.

Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

Carlos Garnacho authored May 07, 2020 and Olivier Fourdan committed May 13, 2020

In this pretty Wine/Proton specific kludge, we try to handle confining grabs
on InputOnly windows by trying to find the InputOutput window that the pointer
would get visually confined to.

The grabbing window and the visible window come from different clients, so
we used to simply resort to the pointer focus. This is troublesome though, as
the call may happen very soon at a time that the toplevel wasn't yet mapped by
the Wayland compositor, so the pointer focus may well be out of date soon.

In these situations, it does seem that even though the confining grab happens
too early to have the wayland surface mapped, the xserver view of the WindowPtr
does already reflect the size. Use this to find out the better window to
assign the confining grab to, one whose geometry fully contains the InputOnly
window's.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

xwl_seat_maybe_lock_on_hidden_cursor() checks that the value of
cursor_confinement_window is not NULL, yet there is no code path
that could lead to this.

Remove the test for cursor_confinement_window being set, it's useless.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

When an X11 client issues a ConfinePointer wit ha hidden cursor,
Xwayland may translate that as a pointer lock.

However, if the pointer is located on another window at the time,
the request may be ignored, even if the pointer later enters the window.

To avoid that issue, check again if locking the pointer with a hidden
cursor is needed when pointer enters a surface.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>