GalaxyCore GC2607 camera sensor not supported in libcamhal (Meteor Lake)

[pkondaurov]

System Information

• OS: Ubuntu 24.04.3 LTS (Noble)
• Kernel: 6.14.0-37-generic
• CPU: Intel Core Ultra 7 155H (Meteor Lake)
• Laptop: Huawei MateBook (ENZH-XX / M1010)
• Camera sensor: GalaxyCore GC2607 (ACPI ID: GCTI2607)

Problem Description

The GC2607 camera sensor is properly detected by the kernel:

intel-ipu6 0000:00:05.0: Found supported sensor GCTI2607:00
intel-ipu6 0000:00:05.0: Connected 1 cameras

The gc2607 kernel driver (from linux-modules-ipu6) is loaded and the sensor responds to v4l2-ctl commands on /dev/v4l-subdev6.

However, icamerasrc does not list gc2607 as an available device. Running gst-inspect-1.0 icamerasrc shows only ar0234_usb variants in the device-name enum.

Root Cause

The ipu6epmtl configuration does not include GC2607 sensor support:

• No gc2607-uf.xml in config/linux/ipu6epmtl/sensors/
• No GC2607 entry in libcamhal_profile.xml availableSensors
• No AIQB tuning file for GC2607

Steps to Reproduce

1. Use a Huawei laptop with Intel Meteor Lake CPU and GC2607 camera
2. Install Ubuntu 24.04 with intel-ipu6 packages
3. Check kernel log: dmesg | grep -i gc2607 - sensor is found
4. Run gst-inspect-1.0 icamerasrc | grep device-name - gc2607 not listed
5. Run cheese - "No device found"

Expected Behavior

GC2607 camera should be available in icamerasrc and work with applications like Cheese, Firefox WebRTC, etc.

Request

Please add GC2607 sensor configuration to ipu6-camera-hal for Meteor Lake (ipu6epmtl):

• Sensor XML configuration (gc2607-uf.xml)
• AIQB tuning file
• Update libcamhal_profile.xml to include gc2607

Additional Information

The kernel driver for gc2607 exists in intel/ipu6-drivers and works correctly. The missing piece is the userspace HAL configuration.

Sensor details from v4l2-ctl:

exposure: min=4 max=2002
analogue_gain: min=0 max=16
link_frequency: 336000000
pixel_rate: 134400000
format: SGRBG10_1X10/1920x1080

[yegor-alexeyev]

The gc2607 kernel driver (from linux-modules-ipu6) is loaded and the sensor responds to v4l2-ctl commands on /dev/v4l-subdev6.
Where is it? I can't find it.

[pkondaurov]

Good question! I apologize for the inaccuracy — the gc2607 kernel driver is not from linux-modules-ipu6. It's a custom driver that we built from scratch based on the reference implementation from the Ingenic T41 platform (MIPS), combined with a patched ipu-bridge to recognize the GCTI2607 ACPI HID.

Let me give you a full picture of what we have and what's still missing.

What works

We have a complete, working camera pipeline — but it's all custom userspace processing, bypassing Intel's HAL entirely:

1. Kernel driver: Custom gc2607.ko V4L2 subdev driver (abbood/gc2607-v4l2-driver) + patched ipu-bridge.ko with GCTI2607 support
2. ACPI SSDT override: Fixes BIOS defaults — enables GC2607 (L0EN=1), disables fake OV01A1S/OV13B10 entries (L1EN=0, L2EN=0), fixes DOVDD power rail (C0F2=0x0D→0x12 to get a regulator instead of a privacy LED)
3. Capture: Raw Bayer frames from /dev/video33 — SGRBG10, 1920x1080@30fps via IPU6 ISYS
4. Userspace ISP daemon (camera_daemon.py): A Python daemon that captures raw Bayer → applies a software ISP pipeline (temporal noise reduction, auto-normalization, demosaic, white balance, tone mapping, chroma denoising) → outputs processed BGR frames to v4l2loopback (/dev/video0)
5. Video calls work in Chrome and Telegram via the virtual "Intel MIPI Camera" device

What doesn't work / problems

• No icamerasrc / libcamhal support — that's the whole point of this issue. Without the Intel HAL tuning (3A algorithms, sensor-specific AIQB, noise reduction, etc.), we're doing everything in Python which is slow and produces mediocre quality
• Image quality is poor — the raw sensor output uses only ~12% of the 10-bit dynamic range at default settings. We had to push digital gain registers (0x020c) via i2c to get usable signal, but it's still far from what you'd get on Windows with a properly tuned ISP
• ~9 fps — Python ISP processing takes ~100ms/frame, so we're limited to about 9-10 fps instead of the native 30fps
• Exposure/VTS registers behave unexpectedly — changing VTS from 2003 to 8000 barely affects brightness, which suggests either internal auto-exposure or some undocumented sensor behavior

Hardware details (HUAWEI MateBook GT 14, ENZH-XX)

• CPU: Intel Core Ultra 7 155H (Meteor Lake)
• Real sensor: GalaxyCore GC2607 at i2c-3 @ 0x37, Chip ID 0x2607
• Fake BIOS entries: OV01A1S (OVTI01AS), OV13B10 (OVTIDB10) — no physical sensors, no I2C response
• Kernel: 6.17.0-14-generic (Ubuntu 24.04)
• SSDT override: Loaded via initramfs hook (NOT GRUB_EARLY_INITRD_LINUX_CUSTOM — that breaks boot)

Key sensor registers we discovered

Register	Default	Our setting	Effect
0x020c/0d (digital gain)	0x04	0x0C	Main brightness lever — 3x more signal
0x0030-33 (black level offset)	0x80	0x20	Reduces black level pedestal
0x0070-73 (BL calibration)	0x40	0x00	Further reduces black level
0x00b8/b9 (VTS)	0x07D3 (2003)	—	Changing has minimal effect on brightness (unexplained)

What we actually need from Intel

The real fix is proper ipu6-camera-hal support:

1. Sensor XML configuration (gc2607-uf.xml) with correct register maps, exposure/gain curves
2. AIQB tuning file for 3A algorithms (auto-exposure, auto-white-balance, auto-focus — though GC2607 is fixed focus)
3. Entry in libcamhal_profile.xml for Meteor Lake (ipu6epmtl)
4. This would give us native icamerasrc support with hardware-accelerated ISP, proper AE/AWB, and 30fps

Your setup (VGHH-XX)

I saw your comments on intel/ipu6-drivers#399 — you also have a Meteor Lake Huawei with GC2607. If you're using the same custom driver approach, I'm happy to share:

• The full SSDT override DSL
• The camera daemon with ISP pipeline
• Register experiment results

All our work is documented in the gc2607-v4l2-driver repo, including a detailed setup guide.

---

Tested on: HUAWEI MateBook GT 14 (ENZH-XX), Intel Core Ultra 7 155H, Ubuntu 24.04, kernel 6.17.0-14-generic