<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style> </head> <body dir="ltr"> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Thanks for the reply! </div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> I have a big update: it's not the screen refresh at all. </div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> 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? </div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> And events are delivered immediately if I'm also running an app like weston-simple-egl or weston-simple-damage.</div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> I'll check the <span style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 255, 255); display: inline !important">WAYLAND_DEBUG / socket flushing.</span></div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0);"> Thanks! </div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0);"> <br> <hr tabindex="-1" style="display:inline-block; width:98%;"> <b>From:</b> Pekka Paalanen<br> <b>Sent:</b> Tuesday, February 11, 2020 3:38 AM<br> <b>To:</b> Josh Simonot<br> <b>Cc:</b> wayland-devel@lists.freedesktop.org<br> <b>Subject:</b> Re: repaint after notify_button() ? <div><br> </div> </div> <div class="BodyFragment"><font size="2"><span style="font-size:11pt;"> <div class="PlainText">On Mon, 10 Feb 2020 21:49:54 +0000<br> Josh Simonot <jsimonot@live.ca> wrote:<br> <br> > Hello,<br> > <br> > I'm using compositor-drm.c as a starting point and am injecting<br> > remote input events, using compositor-rdp.c as an example.<br> > <br> > Currently the output doesn't repaint after "clicking" on a button by calling:<br> > notify_motion_absolute(seat, evtime, x, y);<br> > notify_button(seat, evtime, btn, state);<br> > notify_pointer_frame(seat);<br> > (with WL_POINTER_BUTTON_STATE_PRESSED, then WL_POINTER_BUTTON_STATE_RELEASED)<br> > <br> > I finally see the result of the button press after the clock updates,<br> > or if I run any gl app in the background (ex. weston-simple-egl).<br> > The buttons I'm clicking on is to launch weston-terminal and close<br> > the terminal. Same results when clicking within weston-clickdot<br> > app's window. I tried calling:<br> > weston_output_schedule_repaint(&output->base); with no success.<br> > <br> > How can I get these apps to trigger repaint when clicked?<br> <br> Hi,<br> <br> input events are not supposed to cause immediate repaints in the<br> compositor, except for pointer motion and that only for the pointer<br> cursor position. An input event might not result in anything visible on<br> its own, so causing a repaint automatically would be wrong.<br> <br> Whatever (client) ends up receiving the input events may decide they<br> have some effect and repaint a part of their surface(s), which then<br> will cause content damage in the compositor and schedule a repaint.<br> <br> Why that does not seem to work for you, I cannot guess. Nothing comes<br> to mind off-hand. Sounds like a bug somewhere.<br> <br> FWIW, tests/weston-test.c is a plugin that can poke at input too. All<br> the screenshot tests rely on the compositor repainting after any damage<br> from clients, so the damage side should be fine in libweston core.<br> <br> Maybe check what kind of Wayland protocol exchange you see around your<br> remote input events? Comparing WAYLAND_DEBUG=server vs.<br> WAYLAND_DEBUG=client should reveal any socket flushing issues (the<br> messages are printed when queued/dispatched, not when they cross the<br> socket).<br> <br> <br> Thanks,<br> pq<br> </div> </span></font></div> </body> </html>