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: firstname.lastname@example.org Subject: Re: repaint after notify_button() ? On Mon, 10 Feb 2020 21:49:54 +0000 Josh Simonot <jsimo...@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
_______________________________________________ wayland-devel mailing list email@example.com https://lists.freedesktop.org/mailman/listinfo/wayland-devel