repaint after notify_button() ?

[Pekka Paalanen]

On Wed, 12 Feb 2020 17:22:05 +0000
Josh Simonot <jsimonot at live.ca> wrote:

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

Hi,

you seem to be confusing some libwayland-server and libwayland-client
APIs (wl_display_dispatch_pending()). Both unfortunately have a 'struct
wl_display' type, but the two types are distinct and totally
incompatible. So make sure to use only server API with the server-side
library and objects.

There should be no need to force-wake the event loop at all. It wakes
up automatically from epoll_wait() when any file descriptor (including
client sockets, timers and POSIX signals) registered with it is
readable (or sometimes writable, which ever is appropriate).

Before sleeping in epoll, it also flushes out all pending messages out
to clients.

Dispatching an event loop from random places at random times is a bad
idea. Especially if it happens during dispatch, which may well mess
things up: bad message ordering and maybe memory corruption. This means
there is really no place in Weston where you could actually
force-dispatch anything, everything already happens inside dispatch
calls except during compositor start and shutdown.

You say the notify_*() functions are called in time. Next thing is to
check if the related events are sent out in time, and that you can
check with WAYLAND_DEBUG=server or using 'weston-debug proto' (needs
to start weston with --debug). If those are delayed, then we are sure
the issue is in the compositor. If those are in time, then the issue
cannot be in the compositor.

From what call chain to you call the notify_*() functions? An fd event
source of your own? Idle source? Timer source? Or simply from some
arbitrary function already in the DRM-backend?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200213/7fe01b5a/attachment.sig>