search

arcnmx / input-linux-rs

evdev and uinput for Rust
MIT License
33 stars 6 forks source link

`EvdevHandle` (and probably `UInputHandle`) should take ownership of their fds #6

Closed jonas-schievink closed 5 years ago

jonas-schievink commented 5 years ago

Currently, EvdevHandle relies on the user keeping the original file descriptor open while it's alive. This is very odd, since no fd wrapper in std requires this and it requires storing 2 objects instead of just the EvdevHandle.

I think it would be a good idea to instead take ownership of the RawFd and close it on drop. Additionally, EvdevHandle could implement AsRawFd (and IntoRawFd) to accomodate existing uses where the fd is shared (are there any?). Users could also dup the fd before creating the EvdevHandle if they really require shared access to the fd.

What do you think?

arcnmx commented 5 years ago

Yeah, so, this is a relic from when I initially envisioned them maybe being used like EvdevHandle(&file).driver_version()?, like a transient wrapper that higher level abstractions might use. It's silly and makes no sense, and I was too lazy to add a phantom lifetime to the type to boot.

This is also the only way to interface with the crate at the moment, and although I still intend to include nicer interfaces on top of them eventually, I agree that ownership in some way would be appropriate.

arcnmx commented 5 years ago

Addressed in https://github.com/arcnmx/input-linux-rs/commit/b222944b76d8dd6ad552903f4e2dbafef1ee9de2