Open MarijnS95 opened 1 year ago
@raymanfx should I target this to main
? It looks like next
currently isn't really in a ready state, as for example 384e7fbed429e83613edd4a630573240ec782607 uses v4l2_sys
unconditionally which fails the --no-default-features
test. I assume next
is your personal test ground rather than a branch you expect folks to send their contributions to?
@raymanfx ping?
Hi guys, sorry for being MIA. I've been working on other projects and there's only so many hours in a day. I definately want to return to working on this crate and finish the overhaul of the I/O memory API.
@MarijnS95 as you have been involved for quite a bit now, what do you think about taking over maintainership of this crate temporarily? I'm still available for reviews, but don't feel like I can dedicate enough time to API changes / architecture right now.
@raymanfx I figured you'd ask; same problems for me, there's only so much time in a day. And I'm not even using this crate yet, that's still on a soon™ project list somewhere™.
That said I do somehow have a sweet-spot for low-level (typically kernel/OS related) binding crates (ndk
, ash
, windows-rs
, drm-rs
, probably forgot a few more), all the way from expressive APIs to complete Rust'y documentation. I'd gladly be more involved!
On that note, there's still an unfinished Media API in one of my branches :)
The first new commit 22a2365 on
next
switches to theRawFd
type from thestd::os::fd
module which is only available since Rust 1.66. This module also provides anOwnedFd
type which already has aclose()
call in theDrop
implementation, and implements the desiredAsRawFd
(andAsFd
andIntoRawFd
) traits.Note that these types were already stabilized in Rust 1.63 under
std::os::unix::io
, which is now merely a reexport ofstd::os::fd
.This also replaces the forgotten
.fd()
calls with.as_raw_fd()
from from commit 17c2871.