repaint after notify_button() ?

[Josh Simonot]

calling wl_event_loop_dispatch() is not a working solution:  keeps tripping over a few different assertions causing crash, and doesn't seem to dispatch key events.

I've seen:
- page_flip_handler: Assertion `output->page_flip_pending' failed.
- weston_output_finish_frame: Assertion `output->repaint_status == REPAINT_AWAITING_COMPLETION' failed.

________________________________
From: Josh Simonot <JSimonot at live.ca>
Sent: February 12, 2020 11:55 AM
To: Pekka Paalanen <ppaalanen at gmail.com>
Cc: wayland-devel at lists.freedesktop.org <wayland-devel at lists.freedesktop.org>
Subject: Re: repaint after notify_button() ?

The notify_*() functions are called immediately, and then the 10 second delay.  The event loop is definitely sleeping.

What's the best way to wake it up from within the backend?  I tried: wl_event_loop_dispatch(loop, 0); and this works - just not sure if it is the right way to do it (ran into segfault after a short time, not sure if its related...), and feels more like a workaround to the real issue.

I'm also trying wl_display_dispatch_pending() , but am getting undefined symbol at the moment.

________________________________
From: Pekka Paalanen
Sent: Wednesday, February 12, 2020 4:35 AM
To: Josh Simonot
Cc: wayland-devel at lists.freedesktop.org
Subject: Re: repaint after notify_button() ?

On Tue, 11 Feb 2020 15:59:35 +0000
Josh Simonot <JSimonot at live.ca> wrote:

> 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.

Hi,

have you checked at what time you call the notify_*() functions? Are
they called the 10 seconds before or are they already delayed?

Sounds like you might have issues with the compositor event loop, maybe
not servicing your extra event sources in a timely manner. I assume you
are aware that the compositor main event loop does not spin regularly,
it only spins if any event source is ready. Therefore it may sleep for
arbitrarily long times, and clients sending requests can wake it up
which would explain why extra apps can work around it.


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