repaint after notify_button() ?

[Josh Simonot]

Thanks for the reply!
I have a big update: it's not the screen refresh at all.

Using the weston-eventdemo, I see that the pointer events aren't delivered to the app until 10 seconds after clicking.  Maybe that sheds some light on what could be happening?

And events are delivered immediately if I'm also running an app like weston-simple-egl or weston-simple-damage.

I'll check the WAYLAND_DEBUG / socket flushing.

Thanks!

________________________________
From: Pekka Paalanen
Sent: Tuesday, February 11, 2020 3:38 AM
To: Josh Simonot
Cc: wayland-devel at lists.freedesktop.org
Subject: Re: repaint after notify_button() ?

On Mon, 10 Feb 2020 21:49:54 +0000
Josh Simonot <jsimonot at live.ca> wrote:

> Hello,
>
> I'm using compositor-drm.c as a starting point and am injecting
> remote input events, using compositor-rdp.c as an example.
>
> Currently the output doesn't repaint after "clicking" on a button by calling:
>     notify_motion_absolute(seat, evtime, x, y);
>     notify_button(seat, evtime, btn, state);
>     notify_pointer_frame(seat);
> (with WL_POINTER_BUTTON_STATE_PRESSED, then WL_POINTER_BUTTON_STATE_RELEASED)
>
> I finally see the result of the button press after the clock updates,
> or if I run any gl app in the background (ex.  weston-simple-egl).
> The buttons I'm clicking on is to launch weston-terminal and close
> the terminal.  Same results when clicking within weston-clickdot
> app's window.  I tried calling:
> weston_output_schedule_repaint(&output->base); with no success.
>
> How can I get these apps to trigger repaint when clicked?

Hi,

input events are not supposed to cause immediate repaints in the
compositor, except for pointer motion and that only for the pointer
cursor position. An input event might not result in anything visible on
its own, so causing a repaint automatically would be wrong.

Whatever (client) ends up receiving the input events may decide they
have some effect and repaint a part of their surface(s), which then
will cause content damage in the compositor and schedule a repaint.

Why that does not seem to work for you, I cannot guess. Nothing comes
to mind off-hand. Sounds like a bug somewhere.

FWIW, tests/weston-test.c is a plugin that can poke at input too. All
the screenshot tests rely on the compositor repainting after any damage
from clients, so the damage side should be fine in libweston core.

Maybe check what kind of Wayland protocol exchange you see around your
remote input events? Comparing WAYLAND_DEBUG=server vs.
WAYLAND_DEBUG=client should reveal any socket flushing issues (the
messages are printed when queued/dispatched, not when they cross the
socket).


Thanks,
pq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200211/b44a52b7/attachment.htm>