Skip to content

Navigation Menu

Sign in
Sign up

Patch enabling speakers, mic, camera, suspend and hibernate, and touchpad configuration for surface pro 11 intel. - #164

Open
AndreGilerson wants to merge 6 commits into
linux-surface:v6.18-surface-devel from
AndreGilerson:v6.18-surface-devel
Open

Patch enabling speakers, mic, camera, suspend and hibernate, and touchpad configuration for surface pro 11 intel. #164
AndreGilerson wants to merge 6 commits into
linux-surface:v6.18-surface-devel from
AndreGilerson:v6.18-surface-devel

Conversation

@AndreGilerson

@AndreGilerson AndreGilerson commented May 15, 2026

Copy link
Copy Markdown

As requested in linux-surface/linux-surface#1990 a separate PR for the kernel changes. These changes enable audio, camera, suspend/hibernate support on the surface pro for business 11th edition with intel.

Please refer to linux-surface/linux-surface#1990 for the contrib packages that perform additional setup outside the kernel for audio and camera specifically.

Tested with a clean ubuntu 26.04 install. But additional testing is welcome by other users.

The Surface Pro 11 (Intel/Lunar Lake) Type Cover touchpad (045E:0C8D)
needs three fixes:
1. Force clickpad mode: The firmware reports Pad Type = 1 (PRESSUREPAD)
 and exposes 3 HID buttons, so hid-multitouch's clickpad detection
 fails. Add MT_QUIRK_FORCE_BUTTONPAD to force INPUT_PROP_BUTTONPAD.
2. Enable firmware palm rejection: The touchpad firmware detects palms
 and reports Confidence=0 per-contact, but MT_QUIRK_CONFIDENCE was
 only enabled for a whitelist of Win8 classes. Add the Surface Type
 Cover 11 class to the whitelist so the kernel reports MT_TOOL_PALM
 to libinput.
3. Expose whole-pad force sensor: The HID descriptor includes a 16-bit
 force measurement field (Usage Page 0x20 Sensor, Usage 0x0494) that
 was being discarded. Map it to ABS_PRESSURE, guarded by
 MT_QUIRK_FORCE_BUTTONPAD so only the Surface class is affected.
Add the lid GPE (0x2E) used by the Surface Pro 11 with Intel Lunar Lake
processor. The GPE was identified from the DSDT _L2E handler which reads
the lid GPIO pad (0x0018108E) and sends Notify(LID0, 0x80).
Enable speakers and microphone on the Microsoft Surface Pro 11 Business
(Intel Lunar Lake) via SoundWire:
- Add Lunar Lake SoundWire link tables and DMI gate
 (surface_lnl_rt1320_check) for the SP11 RT1320 amplifier + DMIC
 configuration.
- Teach soc_sdw_rt_dmic to bind the RT1320 part IDs so the RT1320 DMIC
 shows up in the HiFi profile (linux-surface issue #1876).
- Force "Playback-/Capture-SmartAmp" stream names for SDW amplifier
 dailinks so the topology binding matches the
 sof-lnl-rt1320-l0.tplg expectations.
On the Microsoft Surface Pro 11 Business (Intel Lunar Lake), the EFI
ResetSystem call with EFI_RESET_SHUTDOWN fails to power off the system
when PCI shutdown callbacks have run for certain devices. Instead of
shutting down, the call returns and the system stays on, draining the
battery completely overnight.
This is the same class of firmware bug seen on the Surface Pro 9 and
Surface Laptop 5 (Alder Lake), where Thunderbolt and GPU driver shutdown
sequences leave the EFI firmware in a state that prevents power off.
Add the Surface Pro 11 to the no_shutdown DMI table (matched via SKU,
since the product name is just "Surface Pro" and overlaps with other
SKUs), and register PCI fixups for the five Lunar Lake devices that
trigger the bug:
 8086:a831 Thunderbolt 4 USB Controller
 8086:a833 Thunderbolt 4 NHI
 8086:a84e Thunderbolt 4 PCI Express Root Port #0
 8086:a84f Thunderbolt 4 PCI Express Root Port linux-surface#1
 8086:64a0 GPU (Intel Arc Graphics 130V/140V)
Add support for cameras on the Microsoft Surface Pro 11 Business
(Intel Lunar Lake / IPU7):
- New Sony IMX681 front camera driver (3844x2640, RAW10, 2-lane CSI-2).
 Register sequences reverse-engineered from Windows I2C traces and
 other IMX sensors. Uses H-flip (reg 0x0101=0x01) to convert native
 RGGB Bayer to GRBG matching the Windows AIQB calibration data.
- OV13858 rear camera: add get_selection pad op for crop / native size
 reporting (required by the IPU7 userspace stack). The v6.17-era
 clock-frequency probe-defer workaround is dropped because v6.18's
 devm_v4l2_sensor_clk_get() helper now handles deferral internally.
- ipu-bridge: register IMX681 (SONY0681) at 969.6 MHz link frequency
 so IPU7 MIPI CSI-2 enumeration sees the SP11 front sensor.
- ipu7: declare MODULE_FIRMWARE entries for the three IPU firmware
 blobs (ipu7, ipu7p5, ipu8) so initrd builders pick them up.
Add support for the STMicroelectronics VD55G0 global shutter IR sensor
used in the Surface Pro 11 (Intel Lunar Lake) for Windows Hello face
authentication.
The driver is based on the official STMicroelectronics out-of-tree driver
(https://github.com/STMicroelectronics/vd55g0-linux-driver) with the
following adaptations for kernel integration and Surface Pro 11 support:
- Added ACPI device ID table for SMO55F0 and acpi_match_table to the
 i2c_driver, enabling automatic binding on ACPI-enumerated devices.
- Changed fwnode endpoint lookup from of_fwnode_handle() to dev_fwnode()
 with ACPI fallback: when no fwnode graph endpoint is found on ACPI
 systems, defaults to 1-lane MIPI at 600 Mbps data rate.
- ipu-bridge: register SMO55F0 so the IPU7 MIPI CSI-2 framework can find
 the IR sensor.
- int3472/common.c: recognise VD55G0 as a sensor device.
- int3472/discrete.c: add a "0x10" GPIO power-rail type so the SP11's
 secondary power rail is registered as a regulator.

zR-JB commented Aug 12, 2026

Copy link
Copy Markdown

@AndreGilerson I opened #176 as a draft/RFC based substantially on your IMX681 work here, with the goal of converging rather than maintaining a separate SP12 driver.

I would prefer if we could eventually split the IMX681/front-camera work into its own focused PR and compare the driver in #176 with your SP11 version. My SP12 version strips out a number of things that I could not verify as necessary on SP12 and keeps only the tested clock/power/reset setup, fixed mode/timing and raw analogue-gain control.

Would you be able to check whether that reduced version also works on SP11? If it does, I'd be interested whether you see any reason to retain the pieces I removed, or whether we could use the smaller driver as the common SP11/SP12 implementation.

I have kept #176 as a draft specifically so we can work out the common implementation and attribution/DCO together first.

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

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /