Some features need certain globals to initialize. In order to deal with
these dependencies, add a way to postpone closures that depend on a
certain set of globals, that later will be invoked when required
globals are all received.
https://bugzilla.gnome.org/show_bug.cgi?id=719819
Instead use asynchronous round trips that is synchronized in the end of
the initialization. This makes it easier to track state, as we won't
dispatch arbitrary Wayland messages while processing globals.
https://bugzilla.gnome.org/show_bug.cgi?id=719819
When we open the connection, we get the wl_output object,
but we return before all the information such as monitor
geometry has arrived, which causes us to misinform early
users of this information. Do a roundtrip here that causes
us to wait until the information is complete. Do the same
for seats, just in case.
https://bugzilla.gnome.org/show_bug.cgi?id=747471
Support scaling of cursors created from themes. The default scale is
always 1, but if the pointer cursor surface enters an output with a
higher scale, load the larger version of the cursor theme and use the
image from that theme.
This assumes the theme size is set to one that fits with an output scale
= 1.
https://bugzilla.gnome.org/show_bug.cgi?id=746141
The gtk-shell Wayland protocol extension is not meant to be backward
compatible right now, so avoid binding to any version that is not the
one supported.
https://bugzilla.gnome.org/show_bug.cgi?id=745721
Before this patch, we'd always allocate a full size SHM buffer via
the wl_shm_pool, even though it would never be used. Instead allocate a
logical 1x1 cairo image surface.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
Some compositors might not offer wl_seat 4 resulting in GTK+ clients not
working on that compositor.
wl_seat 4 introduces keyboard repeat information, but when that information
is missing it is retrieved from settings, hence there's no reason to
require wl_seat 4.
This patch was tested against QtCompositor (5.5, dev branch)
and Weston 1.6.1.
Reviewed-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744172
To properly support multithreaded use we use a global GPrivate
to track the current context. Since we also don't need to track
the current context on the display we move gdk_display_destroy_gl_context
to GdkGLContext::discard.
wayland doesn't strictly follow the XDG_RUNTIME_DIR spec by falling back
to another directory in case the runtime dir is not properly set.
When this variable is unset, wayland will log an error to us, which we
treat as fatal, aborting the entire program.
Skip ourselves all the trouble and don't try to bring up the wayland
backend when we know it will fail in this way.
https://bugzilla.gnome.org/show_bug.cgi?id=738873
The list of devices was being scanned over incorrectly, causing us to
never actually fetch the keymap from the keyboard, as the keyboard was
the second device in the list, not the first.
This causes us to create a new temporary keymap every time, which is
quite expensive, because it involves parsing the entire XKB
file. Scanning the list correctly will cause us to use the XKB rules
file that was passed to us.
This implementation makes the destination side of selections work
similarly to X11's, gdk_selection_convert() triggers data fetching,
which is notified through GDK_SELECTION_NOTIFY events on arrival,
the buffered data is then available through gdk_selection_property_get().
https://bugzilla.gnome.org/show_bug.cgi?id=697855
Weston releases buffers almost immediately after they're done, which
means that GTK+ doesn't use a temporary surface and instead paints
directly onto the SHM backing store that Weston will use.
Normally, after painting to the temporary surface, GTK+ *replaces*
the existing backing surface with CAIRO_OPERATOR_SOURCE. However,
if we immediately paint to the backing surface, it might have junk
from the last paint in it. So clear out the backing surface whenever
somebody calls begin_paint_region().
Maybe we should just always use the temporary surface like the X11
codepath, since that prevents us from having to do weird things like
this, but oh well.
All the globals we care about should appear before doing anything
else, up-front, so a single round-trip after adding the registry
should be more than enough.
The compositing that is meant here is really specific to the
X11 Composite extension, and does not apply to Wayland.
This is very rarely used functionality anyway, and none of
the other backends support it.
Theoretically, we apply the shape mask client-side ourselves
with an ARGB32 pixmap and intersect it to get a union shape,
but I don't particularly care enough to write that code.
Realistic application code using bounding shapes in 2014 is
quite rare.
Add the concept of shell capabilities, which allow the compositor
to advertise support for the app menu and the global menubar,
which are then propagated as GdkSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=707129
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
With the introduction of the use of buffer scaling in ed4fcee4ct we
must request version 3 of the compositor as that is the version of the
surface interface that adds this new functionality. See the following
commit in weston:
commit a85118c1b85df6fbf8f896dca971a5b79a94da71
Author: Jason Ekstrand <jason@jlekstrand.net>
Date: Thu Jun 27 20:17:02 2013 -0500
Use wl_resource_create() for creating resources
This commit sets the version numbers for all added/created objects. The
wl_compositor.create_surface implementation was altered to create a surface
with the same version as the underlying wl_compositor. Since no other
"child interfaces" have version greater than 1, they were all hard-coded to
version 1.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
https://bugzilla.gnome.org/show_bug.cgi?id=703817
We bind to the newer version of the wl_output which supports
the new done and scale events, and if we use this to get the
scale for each monitor (defaulting to 1 if not supported).
When we call _gdk_wayland_display_load_cursor_theme during
the initial opening of the first display, gdk_setting_get does
not work yet, since it relies on the default display/screen
being set, which only happens after open returns.
Instead, just use the screen of this display.
Instead of maintaining the init refcount in regular event handlers that can
fire in case of hotplug or mode changes, use a dedicated sync callback
to wait for roundtrips.
The global_removal argument is the _name_ of the object.
We were comparing it to the _object id_ of the object.
To fix this, store the name at the time the object is bound.
We use a ref-count mechanism to track whether parts of the init sequence
still needs round trips to receive remaining initial state. Typically
we need a couple of roundtrips total to get the global list, then the
input and output configurations, but with the ref-count we avoid making
global assumptions like that.
https://bugzilla.gnome.org/show_bug.cgi?id=696340
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.
In the Wayland backend implementation for gdk_display_get_keymap we enumerate
the known devices and look for an core keyboard device. These device objects
are created when we receive the capabilities for the seat. The seat
capabilities may be received after a request for the keymap so we handle this
by creating a temporary keymap which we then free later when we have the real
one.
Although GDK expects the keymap to be associated with the display under
Wayland this is really associated with the input device so expose this by
finding the first keyboard device.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
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 requires the SHM object be initialised - therefore this is the most
logical (if slightly ugly place.)
We also need to make sure that we do something clever to load the correct
cursor theme.
The data device manager is a global object that provides the support
infrastructure around data devices. These data device objects are the basis
for handling drag and drop as well as selections in Wayland.
Previously all the commands that acted on the shell took the surface that was
to be acted on as parameter. Now we retrieve an object from the shell that
represents its state for the surface. With that wl_shell_surface object we can
then call methods on that.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
