Make wayland_server::create_event_loop public

[valpackett]

It is useful for compositors:

https://github.com/myfreeweb/weston-rs/blob/8222ffab43a41a54ef107454558ca495cbe4d009/weston-rs/src/display.rs#L32-L34

[coveralls]

Coverage remained the same at 0.0% when pulling 23d00fd on myfreeweb:expose-api into 8e6b642 on Smithay:master.

[elinorbgr]

Most of the safety of the EventLoop wrapper relies on the fact that it has exclusive control over the *mut wl_event_loop associated with it (which is typically ensured by it being created at the same time as the Display). For this reason, I'm going to be rather reluctant to merge this as is unless there is a really good reason to do so.

So, if I understand correctly you are working on libweston bindings. I don't know how much control over the event loop libweston requires, but I guess it's not liberal enough that you can just create the display with the wayland-server crate and provide it to it?

[valpackett]

hm, I'm actually creating the display myself. I'm not sure why I have my own wl_display wrapper... oh, probably because I want to create new Display references from a raw *mut wl_display.

[valpackett]

Oh. Actually. I still need this. I have the Rust side implementing an API that Weston calls into.

But maybe for EventLoopHandle instead of EventLoop

[elinorbgr]

If you need it only for EventLoopHandle (registering & implementing new resources, I guess ?), then it is possible that the incoming 0.20 rework (see #165 ) will solve your issue, as it largely decouples resources and implementing them from the EventLoop type, and EventLoopHandle is completely removed. This PR is almost ready, and I'm just checking the few potentials missing bits by working on Smithay/smithay#88 using it.

Overall, this reworks does break a lot of things, but should make many things easier to integrate and handle I believe. Maybe if you summarize the precise uses you need EventLoop and EventLoopHandle for, I can see if some adaptations to wayland-rs 0.20 should be done accordingly?

[valpackett]

registering & implementing new resources, I guess

No. I just need to call add_fd_event_source in a Rust impl that's called from C (libweston).

I just realized though, I can actually use user_data on libweston's compositor object to pass the Rust event loop object through the C world!...

[valpackett]

Done.

I guess I was also slightly confused by the lack of a run method on your Display, but running the EventLoop works fine.