Commit Graph

559 Commits

Author SHA1 Message Date
Matthias Clasen
393df9f7e1 wayland: Avoid compiler warnings
Fix warnings due to -Wdeclaration-after-statement and -Wshadow.
2015-06-02 09:08:14 -04:00
Jonas Ådahl
7fef713224 wayland: Use on globals closure for loading cursor themes
Instead of putting a 'load cursor themes' call when receiving an wl_shm
global, make it a closure that is prepared during initialization.

https://bugzilla.gnome.org/show_bug.cgi?id=719819
2015-05-20 11:45:13 +08:00
Jonas Ådahl
4e9be39518 wayland: Add global object depedency tracking
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
2015-05-20 11:45:13 +08:00
Jonas Ådahl
181e4399f6 wayland: Don't round trip recursively during initialization
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
2015-05-20 10:59:47 +08:00
Matthias Clasen
62b858cf0f Avoid a critical under weston
The ordering of globals in connection setup under weston
is different from mutter, and we end up creating a the
dnd window before any outputs are present. Don't cause
a critical warning in that case.
2015-05-11 22:13:07 -04:00
Matthias Clasen
5434609b21 Wayland: Make css cursor names work
Map css cursor names to traditional X cursor names to increase
our chance of finding a good cursor in the cursor theme.
2015-05-08 13:34:25 -04:00
Matthias Clasen
b1e10f5312 Wayland: trivial reshuffle
Avoid a forward declaration by moving things around.
2015-05-08 13:34:25 -04:00
Alexander Larsson
eb2c9b433f wayland: Don't send bogus values for cursor surface buffer/scale
I was getting really weird values for scale for the blank cursor used
when hiding the cursor in a GtkEntry when typing, this was caused
by gdk_wayland_device_update_window_cursor sending random values
when the returned buffer was NULL.

We fix this by just not sending any buffer or scale updates in this
case.
2015-04-30 10:26:52 +02:00
Fabiano Fidêncio
fea2e7bf35 gdkkeys: Add support to _get_scroll_lock_state()
GdkKeymap already has support for _get_num_lock_state() and
_get_caps_lock_state(). Adding _get_scroll_lock_state() would be good
for completness and some backends (Windows?) could take advantage of
this.
2015-04-27 20:07:52 -03:00
Jonas Ådahl
3da7394b58 wayland: Add support for gtk_window_set_modal
Add two new requests to the gtk_surface interface: set_modal and
unset_modal. The server will currently not do anything special with
input focus, and its up to the client to ignore events on the parent
surface.

This commit bumps the gtk_shell interface version to 2. By connecting to
a Wayland server with another gtk_shell interface version any features
depending on the gtk_shell protocol will not be available.

https://bugzilla.gnome.org/show_bug.cgi?id=745721
2015-04-23 16:09:15 +08:00
Carlos Garnacho
3a3f2e505a wayland: Don't unset the selected mimetype on drop_reply
gdk_wayland_drop_context_set_status() can't do much else currently besides
picking a mimetype (the first one is currently chosen). This may incorrectly
unset the mimetype chosen on .receive(), so the transfer is cancelled before
it even starts.

At the time drop_reply happens, we should have already picked a mimetype
along the way, so only cover for accepted=FALSE in order to unset it.
2015-04-18 18:11:27 +02:00
Carlos Garnacho
42f096c846 wayland: Plug leak
We leak refs on the dest window if it gets set multiple times, expected to
happen as the DnD operation moves across the window.
2015-04-18 18:11:27 +02:00
Carlos Garnacho
0edc9deee5 wayland: Create internal GdkWindow to be set as the DnD source
During drag operations from another client, we currently set no window as
the DnD source. There's paths in upper layers though that rely on it being
set, just that we don't trigger these yet.
2015-04-18 18:11:26 +02:00
Matthias Clasen
b2e19866ea wayland: Wait for output and seat information
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
2015-04-09 00:14:20 -04:00
Matthias Clasen
da16947e21 wayland: Add more debug output 2015-04-09 00:13:37 -04:00
Matthias Clasen
cb750f60f9 wayland: Don't mix free and g_strdup
While it works most of the time, this is technically
not correct.
2015-04-05 18:59:51 -04:00
Jonas Ådahl
71256a0f94 wayland: Set a more correct xdg_surface application id
The "app_id" of a xdg_surface should be the ID that can potentially be
used to get the DBUS name or the .desktop file.

For GtkApplication programs this is often the ID passed when creating the
GtkApplication object, so when available lets use that.

As fallbacks, first try g_get_prgname as it often corresponds to the
basename part of the .dektop file for non-GtkApplication programs.
Otherwise use gdk_get_program_class, even though that string usually
doesn't conform to the expectations of xdg_surface.set_application_id.

https://bugzilla.gnome.org/show_bug.cgi?id=746435
2015-03-31 12:37:50 +08:00
Carlos Garnacho
6c8c37abbb wayland: Silence warnings on clipboard data sending cancellation
During copy/paste, it may be common that we receive several property changes
around the selection atom, this results in warnings when cancelling the previous
write attempt. We already honor the last request properly, so we should just
cancel silently.
2015-03-19 16:05:04 +01:00
Carlos Garnacho
d5160bb950 wayland: Ensure we re-request the target if the fd changes
If we receive wl_data_source.target before .send, the target would already
be cached, but we'd take no action on the new fd.
2015-03-19 16:05:04 +01:00
Carlos Garnacho
a59fd4a9ad wayland: Don't accept the "TARGETS" target on the wl_data_offer
This is handled separately through the data already cached from the
wl_data_offer.offer handler, we can avoid this request entirely then.
2015-03-19 16:05:04 +01:00
Carlos Garnacho
dcfa55ac7e wayland: Fix thinko in wl_data_source.cancelled handler
The wl_data_source may be the clipboard's. Looking up the drag context in
order to get the display isn't going to fare well there. So, just use the
default display, and only look up the drag context when we know we need it.

https://bugzilla.gnome.org/show_bug.cgi?id=746386
2015-03-18 11:21:40 +01:00
Jonas Ådahl
4e930ada32 wayland: Move gtk-shell compatibility version define too
https://bugzilla.gnome.org/show_bug.cgi?id=745721
2015-03-16 13:58:14 -04:00
Jonas Ådahl
225c10bc5a wayland: Don't set the wl_surface user_data twice
wl_surface_add_listener already sets the user data pointer, so no need
to do it separately before.

https://bugzilla.gnome.org/show_bug.cgi?id=746141
2015-03-16 19:53:37 +08:00
Jonas Ådahl
7372ddd2a1 wayland: Ignore setting the same cursor theme as was already set
If the name and size of the theme is identical to the current
configuration, do nothing.

https://bugzilla.gnome.org/show_bug.cgi?id=746141
2015-03-16 19:53:37 +08:00
Jonas Ådahl
465647e964 wayland: Support scaling of theme based cursors
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
2015-03-16 19:53:37 +08:00
Jonas Ådahl
7b2cdabc2e wayland: Put interface version defines in a common place
So far only one, but put it somewhere all files can see it.

https://bugzilla.gnome.org/show_bug.cgi?id=746141
2015-03-16 19:53:37 +08:00
Jonas Ådahl
c7be8fd398 wayland: Don't set cursor surface scale when we don't have a surface
The setting of the the surface scale even when the surface is not
created from a surface was introduced due to a crash when getting the
buffers when dividing by the scale. The only reason I can see this is
that we get the buffer from a non-existing surface when the wl_cursor
has not yet been set.

Instead, use the name field to avoid trying to use the non-existing
surface, effectively avoiding the division-by-zero that way.

https://bugzilla.gnome.org/show_bug.cgi?id=746141
2015-03-16 19:53:37 +08:00
Jonas Ådahl
b4344861a0 wayland: Only bind to supported gtk-shell versions
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
2015-03-11 11:37:37 +08:00
Carlos Garnacho
eaebc2cb4b wayland: Delay wl_subsurface interface creation until the window is shown
It isn't really necessary anytime before, so just make sure it's there only
when the window is visible.

https://bugzilla.gnome.org/show_bug.cgi?id=743427
2015-03-02 12:11:59 +01:00
Carlos Garnacho
c55fcd35fe wayland: Thaw the clock if we hide a GdkWindow mid-frame
When a window is hidden, its surface and all its roles are destroyed,
if this happens when we already issued a wl_surface_commit and are
awaiting for a frame callback, the clock will remain frozen for the
next time the window is shown.

To avoid this, keep track of the wl_surface_frame() calls issued,
and ensure the clock is thawed after hiding. If we happen to receive
the frame callback, it is just ignored.

https://bugzilla.gnome.org/show_bug.cgi?id=743427
2015-03-02 12:11:59 +01:00
Matthias Clasen
af86bc58b9 wayland: Add debug spew 2015-02-28 00:58:05 -05:00
Matthias Clasen
94c5d691df wayland: Formatting fixes 2015-02-28 00:02:30 -05:00
Matthias Clasen
a0eb0e2346 wayland: Apply maximized and fullscreen state
We were just throwing the request away if the app asks to
fullscreen or maximize a window before it has been mapped.
This is something the GdkWindow API explicitly supports,
so make it work by saving the state until the surface exists.

This fixes things under weston. There are bugs in mutter
that keep this from working correctly with gnome-shell.

https://bugzilla.gnome.org/show_bug.cgi?id=745303
2015-02-27 19:09:03 -05:00
Matthias Clasen
3d205a2037 wayland: Drop some pointless lines
No need for these parameter checks, really.
2015-02-27 19:09:03 -05:00
Olivier Fourdan
53028ff3bb wayland: Don't use g_error() on connection lost
When the Wayland compositor vanishes, all applications connected will
receive a SIGPIPE as soon as they try to use wl_display_dispatch().

Do not use g_error() to terminate the applications when this occurs,
g_error() means an error in the application while here it's not truly
the case.

Use g_warning() and exit() instead.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

https://bugzilla.gnome.org/show_bug.cgi?id=745289
2015-02-27 16:26:39 -05:00
Jonas Ådahl
f13157f4bb wayland: Don't allocate a full size SHM buffer when drawing using OpenGL
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
2015-02-24 20:22:03 -05:00
Jonas Ådahl
aa81262f11 wayland: Scale up wl_egl_window according to window scale
In order to support window scales for EGL windows, resize the
wl_egl_window to the window dimension multiplied with the window scale,
just as with SHM window buffers.

https://bugzilla.gnome.org/show_bug.cgi?id=745076
2015-02-24 20:22:03 -05:00
Jonas Ådahl
56c9eac16e wayland: Properly support changing of surface scale
When the preferred surface scale changes, for example when entering a
wl_output with a higher scale than any previous entered output, recreate
the shm surface and redraw the window content with the new window scale.

Before this patch, the internal scale would be changed, but the shm
surface would not be recreated given the new scale, i.e. we'd attach a
buffer for a different scale than wl_surface.set_scale specified.

https://bugzilla.gnome.org/show_bug.cgi?id=745076
2015-02-24 20:22:02 -05:00
Jonas Ådahl
a70b478a5c wayland: Don't ever try to set surface buffer scale when not supported
If the compositor is too old for handling surface buffer scales, never
tyr to set change it. This will effectively always leave it to its
initial state, i.e. 1.

https://bugzilla.gnome.org/show_bug.cgi?id=745076
2015-02-24 20:22:02 -05:00
Carlos Garnacho
e43ec48e83 wayland: Use display from GdkDragContext device
It will be useless to check the source window on the destination side,
it's at the moment always NULL. Fetch the display from the device instead,
which will be set for every GdkDragContext.
2015-02-17 19:50:05 +01:00
Jonas Ådahl
5889905d1d wayland: Update to xdg-shell unstable v5
Only trivial changes needed.

https://bugzilla.gnome.org/show_bug.cgi?id=744455
2015-02-14 20:54:47 -05:00
Pier Luigi Fiorini
6ae521bb32 wayland: Do not require latest wl_seat
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
2015-02-13 19:05:32 -05:00
Emmanuele Bassi
d066e7541e Remove GdkGLProfile
The existence of OpenGL implementations that do not provide the full
core profile compatibility because of reasons beyond the technical, like
llvmpipe not implementing floating point buffers, makes the existence of
GdkGLProfile and documenting the fact that we use core profiles a bit
harder.

Since we do not have any existing profile except the default, we can
remove the GdkGLProfile and its related API from GDK and GTK+, and sweep
the whole thing under the carpet, while we wait for an extension that
lets us ask for the most compatible profile possible.

https://bugzilla.gnome.org/show_bug.cgi?id=744407
2015-02-12 17:51:31 +00:00
Emmanuele Bassi
022724aa69 gl: Drop profile for gdk_window_create_gl_context()
Now that we have a two-stages GL context creation sequence, we can move
the profile to a pre-realize option, like the debug and forward
compatibility bits, or the GL version to use.
2015-02-12 12:34:28 +00:00
Armin K
6886f479fe wayland: Implement minimize support
Use the existing xdg_surface API for minimization.

https://bugzilla.gnome.org/show_bug.cgi?id=695945
2015-02-11 22:01:38 -05:00
Emmanuele Bassi
2d9081d117 wayland/gl: Ensure we use the 3.2 core profile
Emit an error if the profile is different.

https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
f7497daee9 Switch GDK_GL_PROFILE_DEFAULT to mean 3_2_CORE
Instead of LEGACY.

https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:30 +00:00
Emmanuele Bassi
42a895e85e wayland/gl: Use the GdkGLContext options
https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:05 +00:00
Emmanuele Bassi
22e6f37c9c GL: Split GL context creation in two phases
One of the major requests by OpenGL users has been the ability to
specify settings when creating a GL context, like the version to use
or whether the debug support should be enabled.

We have a couple of requirements in terms of API:

 • avoid, if at all possible, the "C arrays of integers with
   attribute, value pairs", which are hard to write and hard
   to bind in non-C languages.
 • allow failing in a recoverable way.
 • do not make the GL context creation API a mess of arguments.

Looking at prior art, it seems that a common pattern is to split the
construction phase in two:

 • a first phase that creates a GL context wrapper object and
   does preliminary checks on the environment.
 • a second phase that creates the backend-specific GL object.

We adopted a similar pattern:

 • gdk_window_create_gl_context() creates a GdkGLContext
 • gdk_gl_context_realize() creates the underlying resources

Calling gdk_gl_context_make_current() also realizes the context, so
simple GL users do not need to care. Advanced users will want to
call gdk_window_create_gl_context(), set up the optional requirements,
and then call gdk_gl_context_realize(). If either of these two steps
fails, it's possible to recover by changing the requirements, or simply
creating a new GdkGLContext instance.

https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 19:10:04 +00:00
Rui Matos
2dd07f346a gdkscreen-wayland: Don't leak wl_output objects
https://bugzilla.gnome.org/show_bug.cgi?id=743633
2015-01-28 17:17:09 +01:00