-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid extra ioctl by allowing control query by description #62
Conversation
I am not entirely convinced increasing the API surface is worth it just to avoid a single ioctl. This might very well be a case of premature optimization. Are you running into some actual issues that motivate this change? |
I only suggested this to be able to pass an |
@raymanfx agreed that it's not a huge difference. Still, my app calls |
50859ac
to
2acb899
Compare
remove old control getter
Bump, after addressing old comment & rebasing this. |
@donkeyteethUX reverse bump: this is close to ready if you address the minor but remaining isuses. |
Thanks -- will-do when I get a chance. I'm swamped at work but haven't forgotten about it. |
Looks good to me. Any objections? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not fond of conflating PRs with unrelated new-Rust-version clippy fixes as it takes away from the main semantic change, but will leave it to @raymanfx to decide to split that out to a separate PR (i.e. do we use rebase merges?).
EDIT: fwiw I've been told inlining format args will be demoted to pedantic.
Ping again, we still have two comments open and shouldn't conflate this PR with unrelated clippy changes. |
src/device.rs
Outdated
/// # Arguments | ||
/// | ||
/// * `id` - Control identifier | ||
pub fn control_from_id(&self, id: u32) -> io::Result<Control> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, this can be removed. We don't need backwards compatibility here, no need to inflate the API surface when the new function does the same thing, but better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed if we're pushing to land this in a breaking release.
EDIT: Which is needed anyway because the signature of the existing fn control()
changed rather than leaving it untouched and introducing a new fn control_from_description()
instead. We probably discussed this a while ago but I forgot.
The new implementation of `control()` takes a `&Description` directly, and callers have enough means to get that `Description` such that we shouldn't cater to the "slower" use-case of letting `libv4l-rs` query it again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I still think the API is a touch too close to the raw C v4l2 API, but we can do iterative improvements. It's something I need to think about and sketch out separately.
@raymanfx do you mean the API added by this PR specifically, or the control API in general? If anything it seems this function is now more high-level by taking something typed instead of a generic |
I was talking about the API in general. This change is fine and I agree with its premises. |
Changes based on discussion on #60, specifically comments from @MarijnS95.
get_control
which takes a&Description
and requires only 1 ioctl.control
getter in favor of more explicitget_control_from_id
(and document preference forget_control
).