Conversation
This was referenced Sep 7, 2026
vrilutza
force-pushed
the
frame-rate-units
branch
from
September 14, 2026 03:43
d05ec83 to
81111e4
Compare
vrilutza
changed the title
The cached frametime is an interval in milliseconds, but the ISP expects a rate in units of 1/256 fps. Multiplying the interval by 256 reverses the request: 40 ms becomes 40 fps rather than 25 fps. G_PARM meanwhile reports a constant 30 fps even when another rate is requested. Store the rate in ISP units and use it for both firmware commands and G_PARM. Convert V4L2 fractions with 64-bit arithmetic, clamp to 2--30 fps, and use exactly 30 fps for the initial value and zero-interval requests. This avoids millisecond truncation and overflow in large fractions. Serialize S_PARM with queue streaming and return EBUSY without changing the cached rate during capture: the commands take effect at channel start. G_PARM reports the accepted setting, rather than promising a live change that the hardware has not received. Based-on: patjak#343
vrilutza
force-pushed
the
frame-rate-units
branch
from
September 17, 2026 08:53
81111e4 to
2e15787
Compare
vrilutza
added a commit
to vrilutza/facetimehd
that referenced
this pull request
Sep 17, 2026
Setting equal minimum and maximum frame rates limits automatic exposure to one frame period. In dim light this prevents the firmware from gathering more light through a longer exposure. Expose EXPOSURE_AUTO_PRIORITY and the automatic exposure mode supported by the firmware. When priority is enabled, allow the minimum rate to drop to 5 fps, or keep the requested rate if it is already lower. Keep the maximum at the requested rate, and update the cached priority only after the firmware accepts the command. Priority defaults to disabled. Enabling it trades frame rate for longer exposure; it does not force the camera to run at 5 fps in all lighting. This change requires the complete frame-rate correction from PR patjak#343. Based-on: patjak#344
vrilutza
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The cached
frametimeis an interval in milliseconds, while the ISP frame-rate commands take a rate in units of 1/256 fps. Multiplying the interval by 256 reverses the request: 40 ms becomes 40 fps instead of 25 fps. A constantG_PARManswer also fails to describe a changed setting.Store the accepted rate directly in ISP units and use it in the firmware commands and
G_PARM. Convert V4L2 fractions with 64-bit arithmetic, clamp to 2–30 fps, and use exactly 30 fps for the default and zero-interval requests. This replaces the previous millisecond representation, which rounded a nominal 30 fps request to a reported 30.303 fps and could overflow while converting large fractions.Serialize
S_PARMagainst queue streaming. ReturnEBUSYwithout changing the cached setting during capture, because these commands currently take effect at channel start. Reporting an accepted setting must not imply a live hardware change that was never applied.Extracted-function regressions cover high-rate clamping, zero requests, large fractions, and an unchanged cache after a rejected live update. In the previously tested combined series, requested 5, 15 and 30 fps were delivered at approximately 5.01, 15.04 and 30.09 fps; a request for 50 fps was reported as 30 and delivered at approximately 30.08. A live update was rejected with
EBUSY.This corrects
S_PARM,G_PARMand the firmware rate commands.ENUM_FRAMEINTERVALSstill advertises the existing 30 fps entry; expanding rate discovery is not implemented here. #344 depends on this complete correction, including the default and reporting behavior.Validation scope: this individual rebased branch builds against Linux 7.1.13+deb14-amd64 with
W=1; the two existing compiler warnings remain. The complete nine-topic series previously passed 57/57 streaming-inclusive v4l2-compliance checks on MacBookPro14,1. Its final source tree is unchanged by the commit-message rewrite. The combined hardware tests are not nine separate hardware certifications, and no new module reload or hardware test was performed for this publication.Revision:
2e15787ca98e49bf85d57ca68eceb7429044ed93.