Conversation
vrilutza
force-pushed
the
g-selection
branch
2 times, most recently
from
September 14, 2026 03:43
b7b7e6d to
b4ec28e
Compare
vrilutza
force-pushed
the
g-selection
branch
from
September 15, 2026 11:05
b4ec28e to
d3fdb35
Compare
Frame-size enumeration describes the output sizes the scaler accepts, but clients also need a native rectangle when choosing among those sizes. Without it, a client with no size preference can select the minimum of a stepwise range instead of the sensor resolution. Report the detected sensor rectangle for CROP_BOUNDS and CROP_DEFAULT, using the existing maximum-size fallback when detection is unavailable. Keep CROP unsupported because the active window depends on the output format; a constant rectangle would misrepresent it. This publishes existing sensor information without changing capture. Apply it before the stepwise enumeration change in PR patjak#331. Based-on: patjak#347
vrilutza
added a commit
to vrilutza/facetimehd
that referenced
this pull request
Sep 17, 2026
The driver accepts output sizes between its minimum and the sensor dimensions, but ENUM_FRAMESIZES advertises only the native size. Clients that rely on enumeration cannot discover the smaller supported sizes. Describe the range with the same width alignment and height increment as format adjustment, keeping one entry for each supported pixel format. This makes enumeration reflect the sizes the driver accepts. Pair this change with the sensor bounds query from PR patjak#347. Userspace must also use those bounds when choosing a default; older clients can still choose the minimum size or fail to handle stepwise enumeration. This compatibility concern also motivated the earlier revert in 545cb18, so compliance alone does not establish client compatibility. Based-on: patjak#331
vrilutza
force-pushed
the
g-selection
branch
from
September 17, 2026 08:53
d3fdb35 to
373ad9a
Compare
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 scaler accepts multiple output sizes, but frame-size enumeration alone does not tell a client which rectangle represents the sensor. A client with no size preference can consequently choose the minimum of a stepwise range.
Expose the detected sensor rectangle through
VIDIOC_G_SELECTIONforCROP_BOUNDSandCROP_DEFAULT, with the existing maximum-size fallback when sensor detection is unavailable. LeaveCROPunsupported: the active crop depends on the negotiated output, so a constant value would be misleading. Capture behavior is unchanged.This pairs with #331. The tested PipeWire build uses the published bounds to choose the native size; publishing them does not establish compatibility with every older client. #347 can be reviewed independently, but #331 should not be merged on the assumption that stepwise enumeration alone preserves the default resolution.
This revision rebases the branch and rewrites the commit explanation. Its code change is identical to the previous revision. The ioctl reported 1296x736 on the tested MacBookPro14,1. In the previously tested combined series, Snapshot also negotiated that size; that is a combined-series observation, not a new isolated test of this PR.
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:
373ad9a37cf395859bf17a71ee10e2a6d5eb9f93.