[PATCH] xwayland: Use frame geometry for resizing shell surface

[Ondřej Majerech]

On 27/08/14 14:38, Pekka Paalanen wrote:
> On Mon, 25 Aug 2014 10:17:48 +0200
> "Nils Chr. Brause" <nilschrbrause at gmail.com> wrote:
>
>> I also noticed this in current master. This seems to fix the problem. :)
>>
>> Reviewed-by: Nils Chr. Brause <nilschrbrause at gmail.com>
>>
>>
>>
>> On Thu, Aug 21, 2014 at 2:51 AM, Ondřej Majerech <majerech.o at gmail.com>
>> wrote:
>>
>>> We want to set the size of the entire window, not just the input area.
>>> This fixes the bug where resizing an X client under XWayland would make
>>> the window snap to a smaller size, and the pointer would then stay a
>>> distance away from the frame.
>>>
>>> Signed-off-by: Ondřej Majerech <majerech.o at gmail.com>
>>> ---
>>>   xwayland/window-manager.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
>>> index f1523f5..36df855 100644
>>> --- a/xwayland/window-manager.c
>>> +++ b/xwayland/window-manager.c
>>> @@ -1009,7 +1009,7 @@ weston_wm_window_draw_decoration(void *data)
>>>                                            input_x, input_y, input_w,
>>> input_h);
>>>
>>>                  shell_interface->set_window_geometry(window->shsurf,
>>> -                                                    input_x, input_y,
>>> input_w, input_h);
>>> +                                                    x, y, width, height);
>>>          }
>>>   }
>
> Hi,
>
> this patch does indeed fix the problem, but I do not understand why.
>
> There is just one wl_surface, I assume. There is the shadow region of
> the decorations. I would think that the input region is the surface
> region without the shadow region. Why is the input region different
> from the window geometry, should those not be the same values here?
>
> The function starts with:
>
> 	weston_wm_window_get_frame_size(window, &width, &height);
> 	weston_wm_window_get_child_position(window, &x, &y);
>
> So width,height becomes the frame width,height, which does not include
> shadows, I believe. That seems ok.
>
> x,y become the top-left corner of the window content in wl_surface
> coordinates? But that's not the right geometry, you should be including
> the decorations too? Or if not decorations, then isn't widht,height
> wrong because those include decorations?

That's right, (x, y) doesn't include decorations. Funnily enough, it 
doesn't seem to matter -- the x, y arguments for set_window_geometry 
seem not to be taking any effect in this case. As a test, I tried 
calling shell_interface->set_window_geometry(window->shsurf, 0, 0, 
width, height);, and the window stayed where it was.

>
> Now, input_{x,y,w,h} are the frame's input rect, including also the
> actual window content with the decorations. Why does using those go so
> far off?
>
> This is a screenshot of the problem:
> http://people.collabora.com/~pq/xwayland-resize-cursor-geometry-bug.png
>
> As you can see, the cursor is roughly twice as much off the corner as
> is the shadow width.
>
> I think there might be something else broken, and this just hides the
> real bug. Can you explain?

I suppose Jasper knows what's going on in his patch. In fact, that was 
my first attempt at fixing the bug as well, but I assumed that was the 
wrong fix, simply because the codebase seems to use 2 * (margin + width) 
everywhere else. :)

-- Ondra