OV2740 intermittently fails after another camera application; frame timeouts and low FPS on ThinkPad X1 Carbon Gen 10

## Description

I am experiencing intermittent problems with the built-in OV2740 camera on a ThinkPad X1 Carbon Gen 10 using Intel IPU6.

Sakari Ailus from linux-media suggested that I report the Intel Camera HAL portion of the problem to this repository.

### Hardware

- Laptop: Lenovo ThinkPad X1 Carbon Gen 10
- Camera sensor: OV2740
- Camera interface: Intel IPU6
- IPU6 hardware version: 5
- Sensor: `ov2740 17-0036`

### Software

- OS: CachyOS
- Kernel: `7.1.8-1-cachyos`
- libcamera: `0.7.0+ov01a10.2`
- Application: `qcam`
- Intel Camera HAL / libcamhal

## Problems

There appear to be two related problems.

### 1. Camera state-dependent failure

`qcam` can successfully initialize and stream from the camera when it is the first camera application to access it.

However, after another camera application has accessed the camera, `qcam` can sometimes fail to open or configure the camera.

One failure produced:

Failed to open camera device 0: -38 (errno=13)
Failed to configure camera

In another failure, qcam successfully opened and configured the camera and started streaming, but then stopped receiving frames:

Camera device 0 opened successfully
Configured HAL stream: 1280x720 NV12
Streaming started for camera 0

followed by repeated:

CamHAL[WAR] @waitFrame, time out happens, wait recovery

Eventually qcam terminated with SIGABRT.

### 2. Low frame rate

When the camera does work, 1280x720 video is only approximately 10–11 FPS.

I am not sure whether this is caused by the Camera HAL, IPU6 configuration, sensor configuration, or another part of the pipeline.

## Successful qcam run

The same system can successfully initialize and stream the camera.

For example:

Found IPU6 camera 0: ov2740-uf (facing=0)
Adding camera 'ipu6-ov2740-uf-0'
Opening camera device 0
Camera device 0 opened successfully
Configured HAL stream: 1280x720 NV12
Streaming started for camera 0
Streaming stopped for camera 0

This suggests that the camera is supported and can function correctly, but its behavior is not consistent between camera sessions.

## Kernel messages during a failed streaming attempt

During one failed streaming attempt, the kernel reported CSI2 errors including:

Payload checksum (CRC) error
Single packet header error corrected
Multiple packet header errors detected
Transfer FIFO overflow
Incomplete long packet detected
Frame sync error
Inter-frame long packet discarded

This was followed by:

stream stop time out
stream close error: 3

## Additional information

The media topology shows the OV2740 connected to Intel IPU6 CSI2 1 and the enabled capture path is:

ov2740 17-0036
-> Intel IPU6 CSI2 1
-> Intel IPU6 ISYS Capture 8
-> /dev/video8

The sensor reports:

SGRBG10_1X10/1932x1092

The ISYS capture node reports support for several Bayer and converted formats, including BG10, UYVY, YUYV, RGBP and BGR3.

I initially tested `/dev/video8` directly using v4l2-ctl. This resulted in `VIDIOC_STREAMON` failing with `Broken pipe`.

I understand from the discussion on linux-media that this direct test does not demonstrate a kernel streaming failure because the media-controller pipeline has not been configured. `qcam` configures the pipeline through libcamera before streaming.

## Question

Could you advise whether the intermittent camera state/failure and the approximately 10–11 FPS performance are known Camera HAL issues?

In particular, I would like to determine:

1. Why the camera can work when qcam is started first but fail after another camera application has accessed it.
2. Whether the CSI2 errors and frame timeouts indicate a Camera HAL/IPU6 configuration problem.
3. Whether the approximately 10–11 FPS at 1280x720 is expected for this configuration or indicates a problem.
4. What additional tests or logs would be useful to diagnose this.

I can provide the complete dmesg, media topology, and qcam logs if needed.

[qcam-cachyos-success.txt](https://github.com/user-attachments/files/31390629/qcam-cachyos-success.txt)
[dmesg-cachyos-qcam-failure.txt](https://github.com/user-attachments/files/31390628/dmesg-cachyos-qcam-failure.txt)

[v4l2-qcam-failure.txt](https://github.com/user-attachments/files/31390747/v4l2-qcam-failure.txt)
[media-qcam-failure.txt](https://github.com/user-attachments/files/31390748/media-qcam-failure.txt)

Start by reviewing the attached qcam, dmesg, v4l2, and media logs, then reproduce streaming after another camera application has accessed the OV2740. Compare the successful and failed qcam runs, the /dev/video8 pipeline details, CSI2 errors, frame timeouts, and reported FPS. Done means identifying whether the failure is in the Camera HAL/IPU6 path and documenting the evidence or additional logs needed.

Written by the indexing model from the issue text.