2009-06-25 18:56:15 -04:00
|
|
|
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
|
|
|
|
|
|
|
|
|
|
#ifndef META_COMPOSITOR_PRIVATE_H
|
|
|
|
|
#define META_COMPOSITOR_PRIVATE_H
|
|
|
|
|
|
2009-06-26 15:33:20 -04:00
|
|
|
#include <X11/extensions/Xfixes.h>
|
|
|
|
|
|
compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scope
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
2020-07-08 10:53:14 -04:00
|
|
|
#include "clutter/clutter-mutter.h"
|
2018-07-10 04:36:24 -04:00
|
|
|
#include "clutter/clutter.h"
|
|
|
|
|
#include "compositor/meta-plugin-manager.h"
|
|
|
|
|
#include "compositor/meta-window-actor-private.h"
|
|
|
|
|
#include "meta/compositor.h"
|
|
|
|
|
#include "meta/display.h"
|
2009-06-25 18:56:15 -04:00
|
|
|
|
2019-08-14 13:04:41 -04:00
|
|
|
/* Wait 2ms after vblank before starting to draw next frame */
|
|
|
|
|
#define META_SYNC_DELAY 2
|
2014-05-12 09:11:53 -04:00
|
|
|
|
2020-03-03 03:32:33 -05:00
|
|
|
typedef struct _MetaLaters MetaLaters;
|
|
|
|
|
|
2019-08-14 13:04:41 -04:00
|
|
|
struct _MetaCompositorClass
|
|
|
|
|
{
|
|
|
|
|
GObjectClass parent_class;
|
2019-08-14 17:25:54 -04:00
|
|
|
|
2020-03-03 03:27:33 -05:00
|
|
|
gboolean (* manage) (MetaCompositor *compositor,
|
|
|
|
|
GError **error);
|
2019-08-14 17:25:54 -04:00
|
|
|
void (* unmanage) (MetaCompositor *compositor);
|
clutter: Paint views with individual frame clocks
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 18:27:56 -04:00
|
|
|
void (* before_paint) (MetaCompositor *compositor,
|
|
|
|
|
ClutterStageView *stage_view);
|
|
|
|
|
void (* after_paint) (MetaCompositor *compositor,
|
|
|
|
|
ClutterStageView *stage_view);
|
2019-08-14 17:25:54 -04:00
|
|
|
void (* remove_window) (MetaCompositor *compositor,
|
|
|
|
|
MetaWindow *window);
|
compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scope
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
2020-07-08 10:53:14 -04:00
|
|
|
int64_t (* monotonic_to_high_res_xserver_time) (MetaCompositor *compositor,
|
|
|
|
|
int64_t time_us);
|
2021-02-13 06:48:31 -05:00
|
|
|
void (* grab_begin) (MetaCompositor *compositor);
|
|
|
|
|
void (* grab_end) (MetaCompositor *compositor);
|
2009-06-26 15:33:20 -04:00
|
|
|
};
|
|
|
|
|
|
2020-03-03 03:27:33 -05:00
|
|
|
gboolean meta_compositor_do_manage (MetaCompositor *compositor,
|
|
|
|
|
GError **error);
|
|
|
|
|
|
2019-08-14 13:04:41 -04:00
|
|
|
void meta_compositor_remove_window_actor (MetaCompositor *compositor,
|
|
|
|
|
MetaWindowActor *window_actor);
|
2012-11-12 14:11:08 -05:00
|
|
|
|
2014-03-18 17:31:22 -04:00
|
|
|
void meta_switch_workspace_completed (MetaCompositor *compositor);
|
2010-10-18 13:27:14 -04:00
|
|
|
|
2019-08-14 13:04:41 -04:00
|
|
|
MetaPluginManager * meta_compositor_get_plugin_manager (MetaCompositor *compositor);
|
|
|
|
|
|
compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scope
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
2020-07-08 10:53:14 -04:00
|
|
|
int64_t meta_compositor_monotonic_to_high_res_xserver_time (MetaCompositor *compositor,
|
|
|
|
|
int64_t monotonic_time_us);
|
2012-11-12 14:09:38 -05:00
|
|
|
|
2016-03-07 23:10:21 -05:00
|
|
|
void meta_compositor_flash_window (MetaCompositor *compositor,
|
|
|
|
|
MetaWindow *window);
|
|
|
|
|
|
2017-01-26 13:48:52 -05:00
|
|
|
MetaCloseDialog * meta_compositor_create_close_dialog (MetaCompositor *compositor,
|
|
|
|
|
MetaWindow *window);
|
|
|
|
|
|
2017-06-14 05:20:54 -04:00
|
|
|
MetaInhibitShortcutsDialog * meta_compositor_create_inhibit_shortcuts_dialog (MetaCompositor *compositor,
|
|
|
|
|
MetaWindow *window);
|
|
|
|
|
|
2019-02-20 05:07:22 -05:00
|
|
|
void meta_compositor_locate_pointer (MetaCompositor *compositor);
|
|
|
|
|
|
2019-05-24 15:04:56 -04:00
|
|
|
void meta_compositor_redirect_x11_windows (MetaCompositor *compositor);
|
|
|
|
|
|
2019-08-14 17:25:54 -04:00
|
|
|
gboolean meta_compositor_is_unredirect_inhibited (MetaCompositor *compositor);
|
|
|
|
|
|
2019-08-14 13:04:41 -04:00
|
|
|
MetaDisplay * meta_compositor_get_display (MetaCompositor *compositor);
|
|
|
|
|
|
2022-02-05 07:12:48 -05:00
|
|
|
MetaBackend * meta_compositor_get_backend (MetaCompositor *compositor);
|
|
|
|
|
|
2019-08-14 17:25:54 -04:00
|
|
|
MetaWindowActor * meta_compositor_get_top_window_actor (MetaCompositor *compositor);
|
2019-08-14 13:04:41 -04:00
|
|
|
|
|
|
|
|
ClutterStage * meta_compositor_get_stage (MetaCompositor *compositor);
|
|
|
|
|
|
|
|
|
|
gboolean meta_compositor_is_switching_workspace (MetaCompositor *compositor);
|
|
|
|
|
|
2021-11-17 17:31:11 -05:00
|
|
|
void meta_compositor_grab_begin (MetaCompositor *compositor);
|
|
|
|
|
void meta_compositor_grab_end (MetaCompositor *compositor);
|
|
|
|
|
|
compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scope
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
2020-07-08 10:53:14 -04:00
|
|
|
/*
|
|
|
|
|
* This function takes a 64 bit time stamp from the monotonic clock, and clamps
|
|
|
|
|
* it to the scope of the X server clock, without losing the granularity.
|
|
|
|
|
*/
|
|
|
|
|
static inline int64_t
|
|
|
|
|
meta_translate_to_high_res_xserver_time (int64_t time_us)
|
|
|
|
|
{
|
|
|
|
|
int64_t us;
|
|
|
|
|
int64_t ms;
|
|
|
|
|
|
|
|
|
|
us = time_us % 1000;
|
|
|
|
|
ms = time_us / 1000;
|
|
|
|
|
|
|
|
|
|
return ms2us (ms & 0xffffffff) + us;
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-25 18:56:15 -04:00
|
|
|
#endif /* META_COMPOSITOR_PRIVATE_H */
|