<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 20, 2015 at 1:47 AM, Olivier Fourdan <span dir="ltr"><<a href="mailto:ofourdan@redhat.com" target="_blank">ofourdan@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jasper,<br>
<br>
I was working on the same issue (<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1188289" target="_blank">https://bugzilla.redhat.com/<u></u>show_bug.cgi?id=1188289</a>) but did not think about translating the coordinates!<br>
<br>
I applied your patch along with the patch for mutter (on mutter 3.14.3 as found in F21) not to map the cow but that does not work very well.<br>
<br>
It works, as long as the window is not moved, as soon as the toplevel window is moved, the translated coordinates seem correct but the window returned by miSpriteTrace() is not, e.g. I get the "mutter guard window" instead of the actual expected window.<br>
<br>
Oddly enough the coordinates of the toplevel xwindow (as seen with xprop) are not updated after the move, so that miSpriteTrace() picks the wrong window - Maybe I am missing some other patch in mutter, I'll check that.<br></blockquote><div><br></div><div>Hm, that's strange. We should be configuring the toplevel window on every move -- mutter still is an X11 WM. In fact, for the client to map the combobox in the right place, the toplevel coordinates have to be correct.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That being said, I don't think it's a good idea to make a disruptive change in Xwayland that requires code change in the Wayland compositors, what about Weston or the other Wayland compositors out there, we can't really expect all of them to change their code in a synchronously with Xwayland.<br></blockquote><div><br></div><div>We don't require any changes in Weston, from what I can tell. The window still has to be configured in the correct place for the O-R window to be put in that location. If Weston doesn't configure the window, behavior will be incorrect.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We discussed that with ajax and halfline and the the idea would be rather to check if the cow exists and is mapped (e.g. as in mutter before your patch) then use the current code, otherwise, translate the coordinates as you did.<br></blockquote><div><br></div><div>That doesn't make much sense to me. The issue we have is that the combobox window isn't ever a child of the focused window, it's a separate O-R child of the root. As such, we can't *ever* trace down from the focused window.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i.e. something like that:<br>
<br>
--- a/hw/xwayland/xwayland-input.c<br>
+++ b/hw/xwayland/xwayland-input.c<br>
@@ -32,6 +32,9 @@<br>
#include <xkbsrv.h><br>
#include <xserver-properties.h><br>
#include <inpututils.h><br>
+#ifdef COMPOSITE<br>
+#include "compint.h"<br>
+#endif<br>
<br>
static void<br>
xwl_pointer_control(<u></u>DeviceIntPtr device, PtrCtrl *ctrl)<br>
@@ -628,8 +631,25 @@ xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int x, int y)<span class=""><br>
}<br>
<br>
if (xwl_seat->focus_window) {<br>
- sprite->spriteTraceGood = 2;<br>
- sprite->spriteTrace[1] = xwl_seat->focus_window-><u></u>window;<br></span>
+#ifdef COMPOSITE<br>
+ CompScreenPtr cs;<br>
+<br>
+ /* The compositor may have mapped the COW.<br>
+ * If this is the case, translating to the root coordinates to search<br>
+ * for the window will give us the COW which we don't want, so use the<br>
+ * seat's focused window with relative coordinates instead.<br>
+ */<br>
+ cs = GetCompScreen(screen);<br>
+ if (cs->pOverlayWin && cs->pOverlayWin->mapped) {<br>
+ sprite->spriteTraceGood = 2;<br>
+ sprite->spriteTrace[1] = xwl_seat->focus_window-><u></u>window;<br>
+ return miSpriteTrace(sprite, x, y);<br>
+ }<br>
+#endif<span class=""><br>
+ /* convert to root coordinates */<br>
+ x += xwl_seat->focus_window-><u></u>window->drawable.x;<br>
+ y += xwl_seat->focus_window-><u></u>window->drawable.y;<br>
+ sprite->spriteTraceGood = 1;<br>
return miSpriteTrace(sprite, x, y);<br>
}<br>
else {<br>
<br>
<br></span>
But we still need to make sure it works reliably with translated coordinates.<br>
<br>
Cheers,<br>
Olivier<div class="HOEnZb"><div class="h5"><br>
<br>
On 18/02/15 21:41, Jasper St. Pierre wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some toolkits implement comboboxes or menus or other things through<br>
O-R windows, which aren't children of the focused window. In order to<br>
properly get input on them during grab conditions, we need to trace the<br>
whole input tree, not just the focused window down.<br>
<br>
Signed-off-by: Jasper St. Pierre <<a href="mailto:jstpierre@mecheye.net" target="_blank">jstpierre@mecheye.net</a>><br>
---<br>
hw/xwayland/xwayland-input.c | 6 ++++--<br>
1 file changed, 4 insertions(+), 2 deletions(-)<br>
<br>
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c<br>
index 5e20418..8b96bd2 100644<br>
--- a/hw/xwayland/xwayland-input.c<br>
+++ b/hw/xwayland/xwayland-input.c<br>
@@ -654,8 +654,10 @@ xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int x, int y)<br>
}<br>
<br>
if (xwl_seat->focus_window) {<br>
- sprite->spriteTraceGood = 2;<br>
- sprite->spriteTrace[1] = xwl_seat->focus_window-><u></u>window;<br>
+ /* convert to root coordinates */<br>
+ x += xwl_seat->focus_window-><u></u>window->drawable.x;<br>
+ y += xwl_seat->focus_window-><u></u>window->drawable.y;<br>
+ sprite->spriteTraceGood = 1;<br>
return miSpriteTrace(sprite, x, y);<br>
}<br>
else {<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"> Jasper<br></div>
</div></div>