search

perceptia / perceptia_dev

0 stars 0 forks source link

Crate fragmentation - Discussion #2

Open proton-decay opened 7 years ago

proton-decay commented 7 years ago

When perceptia was starting there was available practically one usable crate for libdrm, libgbm and libudev each. Now more bindings were created, so situation must get organized.

This discussion should answer three questions:

Drakulix commented 7 years ago

I would move my crates, if we form some sort of rust-wayland organisation for sure, if we keep everything generic enough to be used by anyone.

@Timidger and the other devs behind way-cooler might also be interested.

proton-decay commented 7 years ago

@asimonf might be interested.

I'd go with something even more generic than rust-wayland, maybe rust-system?

jplatte commented 7 years ago

What about something around freedesktop, since pretty much all of the listed protocols being implemented / libraries being wrapped or rewritten are part of freedesktop.org?

Drakulix commented 7 years ago

I am not sure, if this might limited the future scope of this project (whatever this is going to be) and I am also not sure if rust-system is not too open. While we will also need to maintain udev,drm and many very low-level unix bindings, the name should reflect the goal of this collaboration.

elinorbgr commented 7 years ago
  • create new one (call it "smithay"? @vberger, is that in scope of your project?)

Well, my goal with Smithay would indeed match what you describe here.

To summarize, I want to develop a library (or a set of libraries, it doesn't matter) that can be used to build compositors, abstracting away as much as possible the heavy work (handling devices, graphic buffers, subsurfaces hierarchy), but in a modular and "pick what you want" approach, so not a big framework to which you would provide a few callbacks like WLC.

Also, I want to make as few assumptions as possible regarding what the compositor would look like. I want projects like https://github.com/evil0sheep/motorcar ( video demo ) or things like that https://www.youtube.com/watch?v=_FjuPn7MXMs to be buildable on top of smithay. So considerations like "workspaces" for example are already too high-level for smithay, at least as a first step (but I'd be in favor of building more elaborate abstractions on top of what smithay would provide, but they should be opt-in).

But yeah, in my view, Smithay is not "some part of a compositor that happens to be separable" libe WLC of libweston are, but an independent project that should (and will) adapt to the needs of the compositors using it (following the dream that there may be more than one), but will not be subordinated to any particular compositor.

If you are okay with this philosophy, the only doubt that remains for me if the question of EGL compatibility with Mesa and Nvidia, as I described in the other issue: https://github.com/perceptia/skylane/issues/1#issuecomment-301789763

trissylegs commented 7 years ago

If I can find the time I'll contribute to what I can.

I'm not that Keen of Freedesktop as a name. Unless the projects are supported officially by feedesktop.org. Otherwise to others it might look like official freedesktop.org project. Also the issue @Drakulix mentioned with scope.

jplatte commented 7 years ago

@HornetBlack Yeah I agree that it shouldn't literally be named something like rust-freedesktop, because of the same reason that it seems like something official then.

But the scope of the freedesktop project is basically the same as the scope of all these crates, so I was thinking that we might be able to find a name that alludes to freedesktop.org, without literally containing the word. ("something around freedesktop")

asimonf commented 7 years ago

With regards to the organization of all this, I believe that under the umbrella of something like "rusty-desktop," we could help the comunity understand that this is a united effort in bringing the desktop to rust.

The individual projects, should be laser-focused on the task at hand, like abstracting or creating rust-binds for specific protocols or libraries. I like the idea that the individual projects should be useful by themselves, while contributing to the task at hand. That should help getting the attention of the developers that have specific use-cases and don't want a bloated crate.

To address the questions proposed by @darkelement, I think that there's no need to start from scratch if there's something we can do about it. I'm more than willing to transfer rust-kms (assuming @darkelement is willing as well), if deemed usable, to this proposed organization in order to better organize the crates and repos. And, as I said, I like the idea of creating some kind of organization that spans the needs of the desktop the same way freedesktop does.

proton-decay commented 7 years ago

I also thought about something like "rust(y)-desktop" (but lets wait couple of days, maybe someone will have even better idea). I'm also for the idea of laser-focus.

From post in other thread by @HornetBlack and crates.io:

  1. libdrm:

    • https://github.com/rust-kms/libdrm-rs
    • authors: @asimonf @darkelement
    • start date: June 20, 2016
    • description: sys part complete, but need cleanup; rusty part has only things I needed; well tested in action
    • https://github.com/HornetBlack/rust-drm
    • authors: @HornetBlack
    • start date: Jan 24, 2017
    • description: "Hash it's own drm ffi bindings of just libdrm/xf86drm{,Mode}.h. And then has a Rust implemention of a lot the features of libdrm. (Using more idomatic rust. It's as thin of a layer over the ioctles (and read) as possible and has basic tokio support (for vblank/page flip events)."
    • https://github.com/Slabity/modesetting-rs
    • authors: @Slabity
    • start date: Mar 1, 2017
    • description: seems to have interesting high level approach

  2. libgbm:

I would go with those that have most downloads from crates.io and others merge their features there.

@ascent12, @Slabity, would you join the efforts?

The rest of libs I (or maybe someone else) will summarize later.

trissylegs commented 7 years ago

For gbm @ascent12's looks nice.

trissylegs commented 7 years ago

The locking stuff I mentioned in Gbm: If you call lock_front_buffer, you must not free the resulting Bo (or egl will crash). I apperntly never fixed it. I was just going to have: BufferLockGuard which implements DerefMut for Bo and calls release when done.

Slabity commented 7 years ago

I am willing to join this effort. I've been working on my modesetting crates for about 3 years now and have been thinking of this exact issue recently.

I'll post more details about my personal goals when I get to my desktop.

Drakulix commented 7 years ago

@darkelement

Really for most downloads? Those crates are usually just the first ones to have done any bindings, no matter if they are actually safe or complete.

The lock_frame_buffer api of @ascent12's wrapper e.g. already looks quite unsafe on first sight.

All of these short comings are the main reasons, I started my gbm and libinput bindings, as I did not like the existing ones. Also I strongly favor generated ffi-bindings then hand-written ones.

My take on the lock_frame_buffer call: https://github.com/Drakulix/gbm.rs/blob/master/src/surface.rs#L44 @Slabity's idea sounds valid as well, I am actually thinking about swapping to that. I really should upload my gbm bindings to crates.io, to improve visibility...

I have no strong preference over the libdrm crates, but I remember @HornetBlack's wrapper to look quite nice.

ascent12 commented 7 years ago

I have no interest in binding these libraries to Rust anymore. If someone submits a PR to my repository, I would probably accept it, but I have no plans to do anything with the code myself.

@Drakulix Yeah, it's pretty crap. My wrapper was purposely designed to be very "thin" and not provide a lot of extra machinery. Also, it was designed a very long time ago (as far as Rust is concerned), and Rust was still missing a lot of features which may have made the design better.

Drakulix commented 7 years ago

@ascent12 To be clear about this, I did not want to insult your or your work. It just looked like it was not getting much attention.

asimonf commented 7 years ago

Ok, so there's clear interest in participating. How about we try to do this one step at a time?

Can we agree on having an umbrella on these individual projects? After that, can we move on to decide which projects, if not from scratch, should join in? I believe in technical merits above all for deciding which projects should be used and I don't hold my work above anyone else's in terms of quality since it's barely more than a thin layer above libdrm.

I agree with @Drakulix on how to decide which projects to use. I'm also partial to generated ffi-bindings as they are easier to maintain, but at least when I tried it for libdrm, it wasn't feasible (or I wasn't able to make it work).

IMHO the umbrella should just serve the purpose of organizing the projects for visibility not for determining what should be done or not. Of course, if we decide that umbrella organization should exist, the projects should at least consider the needs of the goal we as a whole are pushing when deciding what to work next. It would be awesome if a rusty desktop environment would come out from this effort.

proton-decay commented 7 years ago

@Drakulix, What I meant is to use those crates as a base and then merge features from others and reuse the most downloaded crate name. But actually we can reuse the name for new crate, repo address will change anyway... So whatever, don't mind me.

This raises another question: maybe just forget about download count and unify crate names? Like rusty-libdrm, rusty-libgbm-sys, etc...

If no objections I will rename rust-kms to rusty-desktop and we can move discussion there.

@Drakulix, so you created new bindings instead of improving old ones. Any ideas how we can prevent this from happening again when someone comes and dislikes what we want to create now?

asimonf commented 7 years ago

No objections from me.

Drakulix commented 7 years ago

@darkelement

  1. Yes a common prefix (although I am not sure about rusty, that sounds very generic) is a good idea.
  2. For me to rewrite a library, that I know of already exists it takes one out of three things:
    • I question the overall code quality, e.g. by encountering bugs in the first minutes of use and then reading over the code.
    • The project seems to be abandoned a long time ago and was not even finished. I usually do not expect the api to be fleshed out in that case in anyway and I don't expect any PRs to go anywhere.
    • The project has a different design philosophy then I view as the best suited for the project and the author is not interested in changing that.

In case of libinput I did not find any other and in case of libgbm I just did not found any library that seemed to be feature complete and maintained.

I don't see this problem affecting us, if we make sure to actively maintain the crates (at least by using CI to ensure they don't break) and polish them (docs, etc).

proton-decay commented 7 years ago

@Slabity, great @Drakulix, great. I hope you will be the one ensuring quality and vitality of new crates.

For crate names I would prefer even no prefix, but we have to ensure we have access to needed names. In case of libinput we have https://github.com/Drakulix/input.rs and https://github.com/Meptl/libinput. @Meptl, would you join?

Slabity commented 7 years ago

@Meptl told me he would join

proton-decay commented 7 years ago

Invitations sent.

Here: https://github.com/rusty-desktop/rusty-desktop-dev/issues I created threads for discussing libs. Depending on output repos will be imported/created and privileges/responsibilities assigned.

ascent12 commented 7 years ago

@Drakulix

To be clear about this, I did not want to insult your or your work. It just looked like it was not getting much attention.

I'm completely fine with people criticising my work, and I certainly don't see it as an insult. I agree with your points anyway. An thin library wrapper doesn't particularly need a lot of attention, but it still was basically abandoned.

Timidger commented 7 years ago

Just saw this thread, looks like a cool effort! Not sure how much I can contribute, I've focused mostly on Way Cooler / application layer since I lack the prerequisite knowledge to contribute to the lower-level crates themselves.

The only thing I have done is making the (bad) bindings for wlc (whereas @Drakulix bindings are far superior) and tentatively set up bindings to the wlroots project. Neither are necessarily in scope for this.

Would still love to be part of the discussion, as I'm very amendable to a more concentrated effort in the Rust ecosystem for a good desktop experience.