Reusing wl_egl_window for multiple EGL surfaces
virtualpresence.ucla at gmail.com
Thu Oct 30 17:09:12 PDT 2014
I see, on the server side there are helpful APIs
like wl_event_loop_add_timer and wl_event_source_timer_update to integrate
timers into event loop but unfortunately not so on client side. I guess it
might not make sense for libwaylandclient to have such APIs but instead the
app/toolkits that implement the client part must have custom APIs coarsely
mirroring the server's functionality. From what i understand from the file
you pointed to it mainly does -
1) create main epoll_fd during setup
2) add display_fd to epoll_fd and the corresponding task handler and user
3) create and add timer_fd to the epoll_fd with its own task handler and
in main event loop of my simple app just keep performing epoll_wait like in
the file and invoke task handlers for generated events.
I will try to get this integrated into my app and post issues if any. Thank
you for all the help.
On Thu, Oct 30, 2014 at 1:16 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 29 Oct 2014 08:48:12 -0700
> Virtual Presence <virtualpresence.ucla at gmail.com> wrote:
> > Thank you for the detailed gyaan. I will look into the "sub-surface"
> > protocol as an alternative. What I do as of now is have the 2 threads on
> > 3 second timer where threadA renders triangle for 3 seconds then signals
> > mutex condition and wakes up threadB which renders gears for 3 seconds
> > so on and so on. I will also look into the option of reusing the
> > for multiple wl_egl_window. This seems closest to what i had in mind. I
> > would also like to attach 3 second timer signal to the display FD and the
> > custom queue i have setup for the 2 threads so that instead of having a
> > dedicated timer logic I can blend the event handling into the Wayland
> > model. I haven't been successful in doing this though. As an alternative
> > am looking into the option of writing a wl_timer protocol to provide the
> > functionality. Any suggestions on how i can tie in the timer logic or any
> > comments on having a dedicated wl_timer protocol? Thank you for all the
> > help.
> Don't do anything with protocol about timers, unless your only goal is
> to learn how to define new protocols by a throw-away toy example.
> Your client is already polling the wayland connection fd. You can just,
> say, use timerfd API to create an fd for your timer needs, and simply
> add that to the poll set. That is what
> already does (look for display_watch_fd), for instance.
> Or use an event library that offers you everything in a portable
> fashion. Or a real toolkit.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel