<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - gtk_window_present does not bring the window to front under wayland, but does under X" href="https://bugzilla.gnome.org/show_bug.cgi?id=763037#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - gtk_window_present does not bring the window to front under wayland, but does under X" href="https://bugzilla.gnome.org/show_bug.cgi?id=763037">bug 763037</a> from <a href="page.cgi?id=describeuser.html&login=jadahl%40gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>