[Wayland-bugs] [Bug 763037] gtk_window_present does not bring the window to front under wayland, but does under X

gtk+ (GNOME Bugzilla) bugzilla at gnome.org
Mon Mar 7 10:43:27 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=763037

--- Comment #4 from Jonas Ã…dahl <jadahl at gmail.com> ---
FWIW, to properly implement this there some serious surgery is needed in
mutter. 

In summary, we currently end up with a mix of g_get_monotonic_time() and
Xserver timestamps.

Gtk will fetch the last timestamp from the last seen event, pass
GDK_CURRENT_TIME, or extract the timestamp from the startup notification ID (or
get the time passed by the application which should be the timestamp from the
GdkEvent). The event timestamps come from libinput; libinput currently uses
G_CLOCK_MONOTONIC. The startup notification ID timestamp though, comes from the
X server.

On the mutter side, all the code that deals with raising/activating etc
currently assumes the timestamp is from the X server. We have ways to calculate
the approximate X server timestamp from a timestamp from the monotonic clock.

To fix things, we need to change mutter to stop relying on timestamps being
from the X server. We have two options of doing this; one is to have timestamps
to either use the Xserver's clock or the monotonic clock and deal with the
difference everywhere (for example make sure to compare to timestamps from the
same clock). The other, probably more sane, option is to make sure mutter
always uses the monotonic clock internally, and translate all X server
timestamps to monotonic clock time.

Some care need to be show for the startup notification specification as well.
The current spec is pretty X11:y, and requires the timestamp to be from the X
server. We probably can't change the timestamp clock for X11 clients, but we
will need to specify the clock the timestamps should be for Wayland clients
(probably specified to be "the same clock as input events"). That mean that the
startup launcher code (currently in gnome-shell) needs to make sure to generate
an ID with a timestamp from the correct clock given the mode mutter runs in.

When those things are fixed, GDK can pass timestamps from the same clock.

I think the mutter surgery is too risky for 3.20.

One thing we could do for 3.20, however, is to ignore all gtk_window_activate*
requests that use a timestamp that is not the one from the most recent event,
and have mutter fetch the time from the X server, making the rest of the mutter
code believe it the activation request just came with an X server timestamp.
This would just be a temporary hack around the real issue, so I'm not sure its
worth the effort if we are not aiming for 3.20 to be a potential "Wayland by
default" release.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20160307/e7a176bb/attachment.html>


More information about the wayland-bugs mailing list