Skip to content

Surface Pro 7+ Cameras not working #1702

Open
Open
Surface Pro 7+ Cameras not working#1702

Description

@AntonioHinds
AntonioHinds
opened on Mar 6, 2025

On Ubuntu 24.04 LTS, the front and rear cameras on the Surface Pro 7+ are not recognized or functional. Running ls /dev/video* does not list any video devices, and cheese fails to detect the camera.

Steps to Reproduce
Install Ubuntu 24.04 LTS on a Surface Pro 7+.
Open cheese or any webcam application.
Check for video devices using ls /dev/video*.
Expected Behavior
The camera should be detected and function normally in applications like cheese and Zoom.

Actual Behavior
No camera device appears in /dev/.
Applications do not detect the camera.
dmesg | grep -i camera does not show relevant logs.
Possible Cause
The issue seems to be related to missing or incompatible Intel IPU3 (Image Processing Unit) drivers, which are required for Surface devices. The kernel may lack the necessary ipu3-cio2 and ipu3-imgu modules.

Workarounds Tried
Installing v4l-utils and firmware-misc-nonfree
Loading ipu3-cio2 and ipu3-imgu kernel modules (modules not found)
Installing linux-surface kernel (no effect on cameras)
System Info
Device: Surface Pro 7+
OS: Ubuntu 24.04 LTS

Request for Help
Are there any patches or workarounds available to enable camera support on the Surface Pro 7+? Any guidance on required firmware or kernel patches would be appreciated.

Activity

  1. JakobBerg commented on Mar 7, 2025

    @JakobBerg
    JakobBerg
    on Mar 7, 2025

    I haven't gotten it working myself yet, but just saw these comments from a few days ago: #1354 (reply in thread)
    maybe something helpful there?

  2. Moryason commented on Apr 16, 2025

    @Moryason
    Moryason
    on Apr 16, 2025

    Same for SP6 - Linuxmint 22.1

  3. Sevron88 commented on Jul 14, 2026

    @Sevron88
    Sevron88
    on Jul 14, 2026

    Update: both integrated cameras are now streaming successfully on my Microsoft Surface Pro 7+.

    Tested environment:

    • Kernel: 6.19.8-surface-3
    • libcamera: 0.7.0
    • Intel Tiger Lake IPU6 (8086:9a19)

    Front OV5693

    The MIPI_CTRL00 = 0x2d fix from #2171 works on the Surface Pro 7+.

    Camera ID: \_SB_.PC00.I2C2.CAMF
1296x972 SBGGR10
approximately 28.7 fps
10/10 frames captured

    Rear OV8865

    The rear camera initially failed during runtime resume:

    ov8865 i2c-INT347A:00: failed to perform sw reset
ov8865 i2c-INT347A:00: Error -121 runtime-resuming sensor, cannot instantiate VCM

    The INT3472 layer exposed an additional regulator named pwr1, but the OV8865 driver did not request it. The regulator therefore remained disabled with zero consumers.

    After adding optional pwr1 support:

    ov8865 i2c-INT347A:00: using optional pwr1 regulator
ov8865 i2c-INT347A:00: Instantiated dw9719 VCM

    Successful rear-camera captures:

    3264x2448 SBGGR10/RAW
15 fps
10/10 frames captured

    1280x720 ABGR8888/sRGB
30 fps
30/30 frames captured

    Rear-camera RFC and tested patch: #2201

  4. JakobBerg commented on Jul 14, 2026

    @JakobBerg
    JakobBerg
    on Jul 14, 2026

    Awesome, I also fixed front and back cameras for the SP7+, and was actually in the process of submitting it to upstream. Just had to learn about the whole "b4" as I never made such a contribution before.

    Did you also have an issue with certain apps having issues with the image stream?

  5. AntonioHinds commented on Jul 18, 2026

    @AntonioHinds
    AntonioHinds
    on Jul 18, 2026
    Author

    Update: both integrated cameras are now streaming successfully on my Microsoft Surface Pro 7+.

    Tested environment:

    • Kernel: 6.19.8-surface-3
    • libcamera: 0.7.0
    • Intel Tiger Lake IPU6 (8086:9a19)

    Front OV5693

    The MIPI_CTRL00 = 0x2d fix from #2171 works on the Surface Pro 7+.

    Camera ID: \_SB_.PC00.I2C2.CAMF
1296x972 SBGGR10
approximately 28.7 fps
10/10 frames captured

    Rear OV8865

    The rear camera initially failed during runtime resume:

    ov8865 i2c-INT347A:00: failed to perform sw reset
ov8865 i2c-INT347A:00: Error -121 runtime-resuming sensor, cannot instantiate VCM

    The INT3472 layer exposed an additional regulator named pwr1, but the OV8865 driver did not request it. The regulator therefore remained disabled with zero consumers.

    After adding optional pwr1 support:

    ov8865 i2c-INT347A:00: using optional pwr1 regulator
ov8865 i2c-INT347A:00: Instantiated dw9719 VCM

    Successful rear-camera captures:

    3264x2448 SBGGR10/RAW
15 fps
10/10 frames captured

    1280x720 ABGR8888/sRGB
30 fps
30/30 frames captured

    Rear-camera RFC and tested patch: #2201

    II am glad to hear that! Currently I am using Fedora 44 can I ask what sudo/commands you used to get the cameras working especially the front one?

  6. luqqas96 commented on Aug 21, 2026

    @luqqas96
    luqqas96
    on Aug 21, 2026

    Surface Pro 7+ on Fedora 44 — both cameras working. Adding a Fedora data point to
    @Sevron88's, plus one finding on the IR sensor that I have not seen recorded anywhere.
    Kernel 6.19.8-3.surface.fc43 (linux-surface)
    IPU6 Tiger Lake 8086:9a19
    libcamera 0.7.1
    Front ov5693 (INT33BE:00, \_SB_.PC00.I2C2.CAMF) working, 28.6 fps
    Rear ov8865 (INT347A:00) working, 1280x720 @ ~30 fps and 3264x2448 @ 15 fps
    IR ov7251 (INT347E:00) not working

    Two things were needed, matching what is already in this thread:

    1. Front: the MIPI_CTRL00 (0x4800) write from cameras: ov5693: make the IPU6 Surface front cameras stream (Pro 8/9, Go 4) #2171. Without it, every capture ends
      in stream stop time out with zero frames.
    2. Rear: the sensor's DVDD rail is declared by INT3472:01 as GPIO type 0x08, which
      this tree maps to a supply named pwr1 that no driver requests, so the rail is
      registered and never enabled. Full analysis, GPIO sweep and an alternative fix keyed on
      the sensor HID are in my comment on [RFC] cameras: ov8865: enable optional pwr1 supply on Surface Pro 7+ #2201.

    The IR sensor — a distinct, earlier failure

    INT3472:02, which backs the ov7251 at INT347E:00, registers no GPIOs at all. Not
    a mis-typed one — none. That is a different failure from the rear camera's, where the pin
    was present and merely misnamed, and it means the IR sensor cannot be fixed by any amount
    of con_id remapping. Anyone attempting Windows-Hello-style face unlock on this model should
    know that before spending an evening on it.

    Note for anyone tracking ACPI IDs: the front sensor here binds as INT33BE, not
    OVTI5693 — same as the Pro 8 reported in #2171. The OVTI5693 HID patch on linux-media is
    genuinely Pro 9 only; the Pro 7+ matches mainline's existing table.

    Two notes for other Pro 7+ owners on Fedora

  7. dmanresa-saes commented on Aug 27, 2026

    @dmanresa-saes
    dmanresa-saes
    on Aug 27, 2026

    Update for this tracker: all three cameras of the Pro 7+ working, front camera including the IPU6 hardware ISP (PSYS) with Microsoft's own .aiqb colour calibration — colour within ~2% of Windows 11 on the same scene, ~7% CPU. Everything reproducible from https://github.com/dmanresa-saes/surface-ipu6-cameras.

    On top of what's already in this thread (#2171's MIPI_CTRL00 makes the front sensor emit, the int3472 regulator mapping powers the rear), the pieces not previously recorded:

    • Front noise: the "works but noisy" behaviour is the full-resolution readout, not the sensor. The mainline 1296x972 binned mode can be made to stream on IPU6 (per-mode MIPI PLL + analogue registers, vendor readout geometry, mode-dependent vflip, 30 fps cap — all from ov5693.sys); analogue gain indoors drops from 127 (max) to ~15.
    • IR (OV7251): the black frames reported above are the unlit illuminator — it hangs off the sensor strobe (0x3005=0x08, 0x3b81=0xff); plus the INT347E regulator must be named vdda, not avdd, for the driver to find it.
    • Kernel patches for all of this are prepared as additions to the 6.19 cameras patchset: cameras: Surface Pro 7+ — make the binned OV5693 stream on IPU6, drive the IR illuminator, map the int3472 sensor rails #2252.

  8. dmanresa-saes commented on Aug 28, 2026

    @dmanresa-saes
    dmanresa-saes
    on Aug 28, 2026

    @JakobBerg — following up on your July comment: your two series are exactly the missing orientation pieces, and they've been sitting unreviewed for a month, so let's coordinate.

    1. Your flip-polarity series (sp7plus-ov-flips-v2, linux-media): happy to add a Tested-by on a real Surface Pro 7+ — we run both sensors daily (front through the IPU6 hardware ISP, rear through libcamera; full setup in https://github.com/dmanresa-saes/surface-ipu6-cameras). One heads-up before it lands: our binned-mode work for the ov5693 (cameras: Surface Pro 7+ — make the binned OV5693 stream on IPU6, drive the IR illuminator, map the int3472 sensor rails #2252) also programs 0x3810 (per-mode ISP window X offset), so your hflip phase compensation and our mode geometry will need to compose — we'll rebase ours on top of yours and handle the offset parity there.
    2. Your int3472 POWER1→dvdd patch: it's cleaner than the per-device quirk we carried (we've already switched to your approach locally, credited), and Sakari asked on Aug 10 for a resend with linux-media CC'd — is that still on your plate? If you're short on time we're glad to help test or follow up; we'd keep only our INT347E→vdda mapping for the IR camera on top, which your patch doesn't cover.

    Between your orientation/power fixes and our binned mode + IR + userspace work, the SP7+ camera story upstream is nearly complete — good timing to get both series moving again.

  9. luqqas96 commented on Aug 28, 2026

    @luqqas96
    luqqas96
    on Aug 28, 2026

    @dmanresa-saes @JakobBerg — I was not aware of Jakob's int3472 POWER1→dvdd series when I opened #2241. Now that I see it covers the same mechanism, I will close that PR in its favour once the resend to linux-media goes out.

    A few independent data points from a bare-DSDT Pro 7+ on Fedora 44 (6.19.8-3.surface, no initramfs ACPI override) that may be useful for the resend or the Tested-by chain:

    Rear camera (INT347A / ov8865) — validated today against the stock OEM DSDT:
    The type-0x08 pin (0xaf, GPIO 175) mapping to dvdd works on the unmodified firmware table. Kernel log with intel_skl_int3472_discrete.dyndbg=+p:

    int3472-discrete INT3472:01: mapping type 0x08 pin to 0x12 dvdd
int3472-discrete INT3472:01: dvdd  \_SB.GPI0 pin 175 active-high
ov8865 i2c-INT347A:00: Instantiated dw9719 VCM

    30/30 frames captured at 1280×720, 5/5 stress cycles clean.

    IR sensor (INT347E / ov7251) — confirmed independently:
    INT3472:02 registers pin 131 as avdd; the driver requests vdda. Confirmed same name-mismatch mechanism without running any custom code — just dyndbg on the stock kernel:

    int3472-discrete INT3472:02: avdd  \_SB.GPI0 pin 131 active-high
ov7251 i2c-INT347E:00: supply vdda not found, using dummy regulator
ov7251 i2c-INT347E:00: probe with driver ov7251 failed with error -121

    This is a separate device from Dario's — two independent machines confirming the same failure mode.

    OV5693 pedestal — measured independently:
    Sensor physically capped, maximum analog gain (127/127): global median 17/1023 (B=13 G1=15 G2=21 R=24). Matches the ~16 LSB reported in #2252.

    Happy to add a formal Tested-by on Jakob's resend once it hits the list, and to close #2241 cleanly in its favour.

  10. JakobBerg commented on Aug 29, 2026

    @JakobBerg
    JakobBerg
    on Aug 29, 2026

    Fantastic to see so much progress here. Amazing with the IR camera, I didn't even consider to take a go at it. I think the binning and/or fixing userspace issues maybe will solve issues that some apps get a cropped image (GNOME cam) while others just show a black image (firefox).

    @dmanresa-saes Thank you very much! I think a lot of brainpower went into this, it is my first linux contribution. It was good you caught the issue with the front camera, it will have to be reworked so the underlying imagestream is correct.
    I think the back camera is fine.
    For the other patch, I have resent it as v3 with the linux-media as cc now.

    @luqqas96 great contribution as well! As for the resend, it is on the list now ( https://lore.kernel.org/linux-media/[email protected]/T/#u )

  11. luqqas96 commented on Aug 29, 2026

    @luqqas96
    luqqas96
    on Aug 29, 2026

    @JakobBerg Thanks for the update and for linking the v3 resend on lore! Great to see it moving through linux-media and platform-driver-x86. Wishing the series a smooth review and quick merge upstream.

    As agreed, I have closed my standalone PR #2241 in favour of your v3 patchset and the consolidated camera work in #2252 to keep upstream tracking clean.

  12. externalmirrors-syncer
    added a commit that references this issue on Sep 3, 2026

    platform/x86: int3472: map the ov7251 power enable GPIO to "vdda"

    59cab09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions