libdrm - roadmap

[proton-decay]

Discussion about road map for libdrm.

[Slabity]

I'd like a complete reimplementation of libdrm rather than bindings to the xf86drm* code. There's a few things I dislike about the official libdrm library like the fact that it prints messages without the option to turn it off.

I have a crate I can transfer here that just creates bindings to a machine's local drm.h and drm_mode.h files if no one has any objections.

[asimonf]

Would you link to it? Is the code publicly available already?

[Slabity]

All my recent work has been in the atomic branch of my modesetting-rs repo: https://github.com/Slabity/modesetting-rs/tree/atomic

Specifically drm-sys: https://github.com/Slabity/modesetting-rs/tree/atomic/drm-sys

It currently has bindings for x86_64 Linux, but you can use bindgen to build the bindings from scratch.

[Slabity]

On top of that, I've been working on a complete reimplementation of the official libdrm library here. You can take a look at the tests I've written to see how it works. It's pretty much identical to the official libdrm library, but a bit more rustic.

[trissylegs]

It seems somewhat more maintained that mine. You seem to also have done some of the things that are in my todo list.

(Edit; by you I meant @Slabity )

[trissylegs]

A wild drm library appeared: https://github.com/devurandom/libdrm-sweet-rs

It appears to be a wrapper around libdrm.

[Slabity]

Well then I guess I will extract drm-sys and libdrm-rs from my modesetting-rs crate. It won't take too long. I've been wanting to switch to using nix for generating the ioctl functions anyways, so I can use that as an excuse.

I'm also thinking of switching the name from libdrm-rs to just drm-rs. It makes more sense since it wraps around the drm api and not the libdrm library.

EDIT: I've created the drm-rs repo as a very minimal abstraction around the drm api.

[proton-decay]

So do we want to completely abandon libdrm or have four: libdrm-rs-sys, libdrm-rs, drm-rs and modesetting-rs?

[Slabity]

I'm not really interested in having any libdrm bindings. I'd rather work with the DRM api directly and develop drm-sys and drm-rs. If an upper level abstraction is a good idea, we can replace modesetting-rs with it (or give it a new name completely).

In fact, having 3 crates for each FFI project seems like a good plan in general. A generated sys crate, a very low level and safe abstraction on top of it, and finally an easy to use higher abstraction on top of that.

This way if another project doesn't like design decisions we've made in the upper level crate, they can easily make their own based on the low level abstraction we have.

[asimonf]

My only concern is that by not using libdrm bindings and creating new ones this might scare away C switchers. But then, I'm hoping that if they come and want to use drm, hopefully the higher level abstractions are a good enough experience.

Overall, though, I agree with having three crates with incremental levels of abstractions building upon the previous level crate.

El 21 may. 2017 11:48 AM, "Tyler Slabinski" notifications@github.com escribió:

I'm not really interested in having any libdrm bindings. I'd rather work with the DRM api directly and develop drm-sys and drm-rs. If an upper level abstraction is a good idea, we can replace modesetting-rs with it (or give it a new name completely).

In fact, having 3 crates for each FFI project seems like a good plan in general. A generated sys crate, a very low level and safe abstraction on top of it, and finally an easy to use higher abstraction on top of that.

This way if another project doesn't like design decisions we've made in the upper level crate, they can easily make their own based on the low level abstraction we have.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rusty-desktop/rusty-desktop-dev/issues/1#issuecomment-302944862, or mute the thread https://github.com/notifications/unsubscribe-auth/AA51m9SGu-K1uhoLSTDpzCJQrzJGVG0Gks5r8FytgaJpZM4Nfj6q .