[WIP] wayland-rs-0.20.0 #165
Conversation
elinorbgr
force-pushed
the
wayland_rs_20
branch
3 times, most recently
from
f9ed232
to
f28bcf5
Compare
I must be out of the loop with this...is there still an attempt to rewrite Wayland in Rust? |
|
Well, it's mostly a "leave the door open" thing. It's something I've been wanting to work on for some time now, and this refactor allows me to cleanly keep the possibility to do this in the future. Basically, the idea is that as newer versions of mesa use the dmabuf extension protocol internally (rather than wl_drm), there is technically no long-term blocker to have a full rust implementation of the protocol, at least server-side (I don't know how things are regarding nvidia, but I won't make my hopes high...). On the other hand, I want to also experiment with ideas such as "rust-implementation of the protocol with a public C api", which would allow wayland-rs to be a system-wide implementation of wayland. So with this new refactor, the wayland-rs crates have "native_lib" cargo feature, enabled by default, which makes them use the C libs as backend. On day, I may succeed in making a native implementation, in which case removing this feature will use it. (For now, all the code will remain as But there is not timeline nor priority for this. The core reason of this refactor is to address usability issues we encountered in smithay, and try to make the API more rust-friendly overall. |
elinorbgr
force-pushed
the
wayland_rs_20
branch
from
f28bcf5
to
c6ac05f
Compare
|
Ah ok thanks for the update. I remember there was talk a while back about skylane being a potential implementation, but was shot down due to the mesa issues you mentioned. The fact that is unblocked is news to me, and very welcome. I'm way too busy at the moment with Way Cooler and wlroots-rs, but maybe in the future if that is still planned / being worked on I'll look into helping out. At the very least, it will be another implementation which will be nice since everyone just uses the reference one and there should be alternatives (especially in such a safe language). |
elinorbgr
force-pushed
the
wayland_rs_20
branch
from
dec90e7
to
751ec1f
Compare
elinorbgr
force-pushed
the
wayland_rs_20
branch
from
ed3ed4b
to
0b624e1
Compare
|
@mitchmindtree @Drakulix : Thanks for the proofreading! |
|
I'm considering this done, though if someone want to give their opinion on the API, this would be very welcome. I've made 3 examples which I think represent mostly how the API feels like client side, you can see them here: https://github.com/Smithay/wayland-rs/tree/wayland_rs_20/wayland-client/examples I've not made any examples server-side (yet ?), mostly because a minimal meaningful server is much more complex than a minimal meaningful client. But the APIs client-side and server-side are very similar overall. |
| // with version 1 when advertized, and provide a callback that | ||
| // will handle the created wl_seat to implement them | ||
| // | ||
| // NOTE: the type annotations are necessayr because rustc's |
| |seat: Result<NewProxy<_>, _>, ()| { | ||
| // here seat is a result, as failure can happen if the server | ||
| // advertized an lower version than we requested. | ||
| // This cannot happer here as we requested version 1 |
|
|
||
| use wayland_client::protocol::wl_display::RequestsTrait; | ||
|
|
||
| // A minimal example printing the list of globals abvertized by the server and |
elinorbgr
force-pushed
the
wayland_rs_20
branch
from
5bbfb1a
to
df1b632
Compare
|
Alright, this has been polished enough and I'm happy with the current state of things. Minor additional fixes shall come in new PRs an releases. |
Currently WIP, complete rework of the libs to significantly improve the APIs and reduce the unsafe code use, as well as pave the road for a full-rust implementation of the protocol.
TODO:
commons:
scanner:
client:
server: