If we bind to a global with an higher version than implemented, or
we make requests that appeared in a later version, we would get
fatal wayland errors.
https://bugzilla.gnome.org/show_bug.cgi?id=704104
Ths allows the retrieval of the wl_surface before the window is shown.
The surface is still created in the original places since the surface
and shell surface is destroyed when the surface is programmatically
hidden.
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
We track the list of outputs each window is on, and set the
scale to the largest scale value of the outputs. Any time the scale
changes we also emit a configure event.
If we got the release event for the last buffer then we're
fine with writing directly to the window surface, as wayland
will not be looing at it. This saves us from allocating
and copying more data.
There is currently no Wayland protocol for providing presentation
timestamps or hints about when drawing will be presented onscreen.
However, by assuming the straightforward algorithm used by the
DRM backend to Weston, we can reverse engineer the right values.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Combine duplicate code for creating and destroying surfaces.
To make the operation of the destroy() operation more obvious, the
destruction of the (fake) root window at display dispose time is
changed to not be a "foreign" destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Use wl_surface_frame() to get notification when the compositor paints
a frame, and use this to throttle drawing to the compositor's refresh
cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Lazily creating the cairo surface that backs a window when we
first paint to it means that the call to
gdk_wayland_window_attach_image() in
gdk_wayland_window_process_updates_recurse() wasn't working the
first time a window was painted.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
When exposing an area, we were individually damaging and committing
each rectangle, *before* drawing. Surprisingly, this almost worked.
Order things right and only commit once.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Allow to set a GdkWindow to use a custom surface instead of a
wl_shell_surface. It allows to register the surface as a custom type
with some Wayland interface.
https://bugzilla.gnome.org/show_bug.cgi?id=695861
Use separate fields for saving the window dimensions prior to fullscreening
and maximisation. Then use those fields to restore the window dimensions from.
With recent changes in attach semantics, we always need to attach before
committing. Without this changes to the window contents to not get reflected
in the content of the surface.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
We currently use this information to display the title
string in the window list of the desktop shell.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.
Allows to access Wayland specific window information like wl_surface and
wl_shell_surface.
Add gdk_wayland_window_get_wl_surface for getting the Wayland wl_surface
and gdk_wayland_window_get_wl_shell_surface for getting the Wayland
wl_shell_surface.
If we don't have a wl_seat - because a grab hasn't been initialised by GTK+
then fallback to making the shell surface transient to the parent rather than
a popup surface.
This replaces the wl_input_device with wl_pointer, wl_keyboard, wl_touch all
tied together under a wl_seat.
This is quite a radical change in protocol and for now keyboard handling is
disabled.
This allows combo box popup windows to appear in the correct place. This is a
workaround emulating root coordinates by calculating the offset for a chain
of windows that that are relative to each other.
