repaint after notify_button() ?

[Josh Simonot]

Aha!  That's the problem:  I call notify_*() from my own thread which reads a socket fd from a remote server.  Sounds like the correct way to do this is use wl_event_loop_add_fd() to register the socket, and read from the fd in the callback?

I have some non-input messages that need to remain async from weston's event loop (ex. some setup during compositor start),  so I did a test by keeping the notify_*() event calls in my thread and then "dispatch" the event loop by sending a signal over a pipe which I registered with wl_event_loop_add_fd().  This appears to be working!  I just want to make sure there's no obvious problems/race-conditions that come to mind with calling notify_*() asynchronously?

And thanks for all the help!!

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

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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200214/44a26233/attachment.htm>