Repository navigation
Dell Inspiron 14 Plus 7441 - hardware support, open issues and testing #12441
Replies: 26 comments
Camera debug
@rafaelguariento Good to have the AUX read tested and the backlight hook confirmed through a kernel update. The missing [alarm] repo in the devtools profile sounds worth reporting separately so other builders don’t hit the same issue. My Yoga camera uses a patched test kernel based on Bryan O’Donoghue’s CAMSS work and existing Yoga patches from Aleksandrs and others. Bryan’s September 6 series actually includes an OV02E10 patch for your Inspiron 7441. It specifies the sensor address, lanes, clock, reset GPIO and supplies, so that should save you a lot of reconstruction. The CAMSS/CCI/CSIPHY definitions are shared SoC-level pieces, while the sensor wiring and regulators are board-specific. It’s upstream-submitted work, but you’ll need the matching CAMSS and PHY driver changes alongside the DT. Enabling the sensor driver alone won’t cover those dependencies. For the Yoga wiring I used existing patches and Aleksandrs’s decoded firmware resources, rather than decoding the Windows sensor blob myself. I haven’t tested the Dell patch. My working Yoga setup uses an older stack, so I’d start with Bryan’s matched series rather than copying my test DT. That patch targets the RGB camera, not the separate IR sensor. |
Update: camera on the current series (v18 / DTSI v7), plus two Omarchy boot bugsRebuilt the camera stack on the newest revisions and got processed colour video at 30 fps, through the browser relay, on Camera: what changed from the earlier reportApplied to ALARM
Unlike v6, DTSI v7 no longer applies cleanly to 7.2. It needs two backports from linux-next:
The lane fix is still needed and isn't in any posted series. In PHY-API mode the CAMSS endpoint uses camss: use data-lanes starting at 1 for new CSIPHY modediff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 84097d82d..686b051f2 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -4742,7 +4742,8 @@ static const struct parent_dev_ops vfe_parent_dev_ops = {
*/
static int camss_parse_endpoint_node(struct device *dev,
struct fwnode_handle *ep,
- struct camss_async_subdev *csd)
+ struct camss_async_subdev *csd,
+ bool legacy_phy)
{
struct csiphy_lanes_cfg *lncfg = &csd->interface.csi2.lane_cfg;
struct v4l2_mbus_config_mipi_csi2 *mipi_csi2;
@@ -4779,6 +4780,19 @@ static int camss_parse_endpoint_node(struct device *dev,
for (i = 0; i < lncfg->num_data; i++) {
lncfg->data[i].pos = mipi_csi2->data_lanes[i];
lncfg->data[i].pol = mipi_csi2->lane_polarities[i + 1];
+
+ /*
+ * With a standalone CSIPHY node, data-lanes follow the
+ * video-interfaces convention and start at 1, whereas the
+ * CSID lane assignment expects 0-based lane positions.
+ */
+ if (!legacy_phy) {
+ if (!lncfg->data[i].pos) {
+ dev_err(dev, "data-lanes must start at 1\n");
+ return -EINVAL;
+ }
+ lncfg->data[i].pos--;
+ }
}
return 0;
@@ -4841,7 +4855,7 @@ static int camss_parse_ports(struct camss *camss)
goto err_cleanup;
}
- ret = camss_parse_endpoint_node(dev, ep, csd);
+ ret = camss_parse_endpoint_node(dev, ep, csd, camss->legacy_phy);
if (ret < 0)
goto err_cleanup;
}Result: One userspace correction. With Omarchy bug 1: kernel installs produce a boot entry with no device treeThe ISO-installed system boots a UKI ( After that, kernel installs rebuild Omarchy bug 2:
|
Update: cpufreq on CPUs 4–9 fixed, root cause is firmware reporting a zero sustained frequencyThe "only CPUs 0–3 under frequency control" issue is solved on this machine. All three clusters now get a policy and scale under fastfetch now reports Correction to the earlier analysisThe missing OPP tables for cpu4+ in The actual cause
data.turbo = freq > dom->sustained_freq_khz * 1000UL;The X1P-64-100 firmware reports Confirmed without rebuilding, using a kprobe on kprobe used (no rebuild needed)With the fix, the boot log shows the firmware values directly: The fixIgnore a sustained frequency that is below the domain's lowest OPP. Genuine boost OPPs on parts whose firmware reports a sensible sustained frequency are unaffected. The fused-core firmware: arm_scmi: perf: Ignore sustained frequency below the lowest OPPdiff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index 4583d02be..8e7a1aaa3 100644
--- a/drivers/firmware/arm_scmi/perf.c
+++ b/drivers/firmware/arm_scmi/perf.c
@@ -865,14 +865,33 @@ static int scmi_dvfs_device_opps_add(const struct scmi_protocol_handle *ph,
struct device *dev, u32 domain)
{
int idx, ret;
- unsigned long freq;
+ unsigned long freq, min_freq = ULONG_MAX;
struct dev_pm_opp_data data = {};
struct perf_dom_info *dom;
+ bool sustained_valid;
dom = scmi_perf_domain_lookup(ph, domain);
if (IS_ERR(dom))
return PTR_ERR(dom);
+ for (idx = 0; idx < dom->opp_count; idx++) {
+ if (!dom->level_indexing_mode)
+ freq = dom->opp[idx].perf * dom->mult_factor;
+ else
+ freq = dom->opp[idx].indicative_freq * dom->mult_factor;
+ min_freq = min(min_freq, freq);
+ }
+
+ /*
+ * Some firmware reports a sustained frequency below the lowest OPP
+ * (e.g. zero) for some domains. Treating every OPP as turbo then
+ * leaves cpufreq with no usable frequency, so the policy is dropped.
+ */
+ sustained_valid = dom->sustained_freq_khz * 1000UL >= min_freq;
+ if (!sustained_valid)
+ dev_info(dev, "[%d][%s]: sustained freq %u kHz below lowest OPP, not marking turbo OPPs\n",
+ domain, dom->info.name, dom->sustained_freq_khz);
+
for (idx = 0; idx < dom->opp_count; idx++) {
if (!dom->level_indexing_mode)
freq = dom->opp[idx].perf * dom->mult_factor;
@@ -880,7 +899,8 @@ static int scmi_dvfs_device_opps_add(const struct scmi_protocol_handle *ph,
freq = dom->opp[idx].indicative_freq * dom->mult_factor;
/* All OPPs above the sustained frequency are treated as turbo */
- data.turbo = freq > dom->sustained_freq_khz * 1000UL;
+ data.turbo = sustained_valid &&
+ freq > dom->sustained_freq_khz * 1000UL;
data.level = dom->opp[idx].perf;
data.freq = freq;Nothing in mainline 7.3, linux-next (next-20260922) or Ubuntu's Research on the other open issues (7.3, linux-next for 7.4, Ubuntu)
|
Update: shutdown on AC fixed — the EC was never told about standbyShutdown with the charger attached now powers off exactly like on battery. The cause is the embedded controller: on Windows, firmware tells it about Modern Standby, and Linux never did, so with AC attached the EC kept everything powered. In suspend, the keyboard backlight now also goes dark together with the screen, instead of after the 15 s BIOS timeout. What Windows doesThe EC is not in the Linux device tree. The Dell DT only has a
Writing The workaround: two systemd hooksBoth look up the bus by controller address, so they don't depend on the
|
Update: 43-minute suspend with the full stack — ~1.05 W, no regression, still no CX collapseMeasured on
Correction: I subtracted 5–8 W for the ~0.8 min awake, and 24 mWh for the fixed per-cycle cost. The gauge's 10 mWh steps give about ±0.015 W over this duration.
|
Update: ADSP wakeups are firmware-internal, speaker tuning, and lost quiet-boot flagsThe ADSP's ~100 Hz tick comes from its own firmwareIn
None of the Linux drivers that talk to the ADSP drives it, so it looks internal to the ADSP firmware (charger/fuel gauge/audio housekeeping). Whether it is what blocks CX collapse, and whether Windows shows the same tick, can't be settled from the Linux side. Useful for anyone at Qualcomm/Linaro looking at X1E suspend. Side note: unloading and reloading Speakers: why Windows sounds louder, and a PipeWire tuning
|
Update: same EC as the XPS 13 9345 (Linaro's
|
Update: webcam image tuning, a washed-out relay path, and the privacy LEDWhy the browser picture looked flat: the relay's 1080p path
Requesting 1280×720 from the camera removes most of it (and saves CPU). A slightly higher saturation compensates for the rest: Chromium opens the loopback over V4L2 directly (no PipeWire camera flag), so this is exactly what browsers get. A tuning file for the OV02E10libcamera fell back to A diagonal CCM chosen from side-by-side captures fixes both. It is %YAML 1.1
---
version: 1
algorithms:
- BlackLevel:
- Awb:
- Ccm:
ccms:
- ct: 6500
ccm: [ 0.90, 0, 0,
0, 0.90, 0,
0, 0, 1.18 ]
- Adjust:
- Agc:
...Red -10%, green -10% (removes the green tinge) and blue +18%. Skin looks natural and the colours now look right. It is a fixed correction tuned by eye for daylight, not a calibration: under warm lamps the image runs warmer. A proper calibration (per colour temperature, plus sensor properties and a camera-sensor helper for Privacy LEDThe DT has I add it to the installed DTB with |
Update: loud fans fixed — the EC needs temperature reports; privacy LED verifiedThe fans were loud because the EC gets no temperaturesThe EC controls the fans. On Windows, Qualcomm's FECI driver ( Nothing sends these on the Inspiron, so the EC runs the fans hard as a precaution. Sending them made the fans go quiet within a second. I sent the SoC's hottest thermal zone (~41 °C) to all seven IDs from a 60 s test loop; no write errors. The ACPI side isn't involved: the thermal zones' The workaround: a small reporter serviceIt sends the hottest SoC thermal zone as a stand-in for all seven board thermistors every 0.5 s. The SoC runs warmer than the board, so the EC errs toward more cooling. If the service stops, the EC just goes back to loud fans. At a 1 s interval there was one brief fan spike, so I use 0.5 s. It uses ~0.2% of one core.
|
| Windows | ADC channel (PMK8550, sid 1) | Linux constant | EC id |
|---|---|---|---|
| SYS_THERM1 | 0x4a |
ADC7_GPIO1_100K_PU |
0x02 |
| SYS_THERM2 | 0x4b |
ADC7_GPIO2_100K_PU |
0x03 |
| SYS_THERM3 | 0x44 |
ADC7_AMUX_THM1_100K_PU |
0x04 |
| SYS_THERM4 | 0x45 |
ADC7_AMUX_THM2_100K_PU |
0x05 |
| SYS_THERM5 | 0x46 |
ADC7_AMUX_THM3_100K_PU |
0x06 |
| SYS_THERM6 | 0x47 |
ADC7_AMUX_THM4_100K_PU |
0x07 |
| SYS_THERM7 | 0x48 |
ADC7_AMUX_THM5_100K_PU |
0x08 |
The XPS 13 9345 uses the same layout, except that its two GPIO thermistors are on GPIO3/GPIO4. The EC-id order above follows the XPS driver and is my inference. What it needs:
CONFIG_QCOM_SPMI_ADC5_GEN3=m. The driver source is in 7.2, but ALARM's config has it off.- The
pmk8550_vadc: adc@9000node (qcom,spmi-adc5-gen3) from linux-next'shamoa-pmics.dtsi, plus the seven channels above and PMIC GPIO1/GPIO2 pinctrl in analog-input mode. - Report those readings instead of the SoC proxy, via
dell-xps-ecwith an Inspiron compatible and an optional IRQ, or via this service reading IIO.
The EC also stores a per-thermistor "profile". Reading 16 bytes from register 0xB0 returns the same pattern dell-xps-ec writes at probe (01 00 2a | 02 44 29 | 03 44 2b | 04 44 28 | 05 55 …), so it appears to be kept from Windows. I haven't written it.
Privacy LED: verified
With leds/led-names = "privacy" on the OV02E10 node (previous comment), the white camera LED lights whenever the camera streams and goes off when it stops.
Update: speaker tuning v2 — more presence, tweeters high-passedv1 of the PipeWire tuning (posted above) got the balance right, but Windows still sounded more "present". v2 changes three things and closes most of that gap by ear:
The balance fix (right channel ×0.6), low shelf, 450 Hz cut and compressor settings are unchanged. Same caution as before: there is no speaker protection on Linux, so avoid sustained maximum volume. Full
|
Update: real board thermistors now report to the EC (PMK8550 ADC5 Gen3, no kernel reinstall)The SoC-temperature stand-in quieted the fans but made them kick in on every short SoC spike, because the EC saw the SoC hotspot as board heat. The reporter now sends the actual board thermistors, as Windows does. Channel map, confirmed from this machine's Windows driver
PM8550 GPIO1/2 are unused by Linux here (only GPIO10/11 are), so switching them to high-impedance input is safe. Getting the ADC up on the running 7.2.6 kernel
|
Update: power profiles now do something; kernel repackaged as 7.2.6-1.5Power profiles
Verified:
|
Hibernation: freeze/thaw passes, image write hangs — left disabledTested on the patched Tested in stages from the kernel's own debug modes, least risky first:
After the forced reboot the swap signature was still The finer |
Suspend:
|
| provider | blocked by |
|---|---|
4 × qnoc-x1e80100 interconnects (1600000, 1780000, 26400000, interconnect-1) |
aa00000.video-codec |
gcc-x1e80100 100000.clock-controller |
3d6a000.gmu, aa00000.video-codec, aaf0000.clock-controller |
gpucc-x1e80100 3d90000.clock-controller |
3d6a000.gmu |
qcom-rpmhpd (the CX/MX rail votes) |
aa00000.video-codec, aaf0000.clock-controller |
3d6a000.gmu(qcom,adreno-gmu-x185.1): the msm GPU driver uses the GMU node directly and never binds a driver to it. This is a known upstream issue.aa00000.video-codec(qcom,x1e80100-iris):CONFIG_VIDEO_QCOM_IRISis off in the ALARM kernel.aaf0000.clock-controller(qcom,x1e80100-videocc):CONFIG_SM_VIDEOCC_8550is off in the ALARM kernel.
(Jim's Surface also has the crypto engine blocking, since QCE was marked BROKEN upstream. That one doesn't show up here.)
Forcing it at runtime. Each provider has a writable state_synced attribute. It accepts exactly 1 without a newline: echo 1 > returns EINVAL, printf 1 > works.
printf 1 > /sys/devices/platform/soc@0/17500000.rsc/17500000.rsc:power-controller/state_synced
I released them in stages (interconnects, then gcc/gpucc, then rpmhpd). There were no crashes and the display, audio, camera and Wi-Fi were unaffected. Two side effects, both good:
- the CDSP now sleeps: its
qcom_statscount was 0 on every kernel before, and it stayed asleep for the whole suspend below; - the CDSP fastrpc device, which had been stuck in deferred probe since boot, finished probing.
Suspend, 29 min, charger unplugged: ~0.90 W (previously ~1.01–1.07 W). This is a single run; a longer one is in progress. aosd/cxsd/ddr are still 0, so something else still holds CX. The ADSP still wakes ~96×/s.
Made persistent with fw_devlink.sync_state=timeout on the kernel cmdline (a Limine drop-in /etc/limine-entry-tool.d/sync-state.conf). After deferred_probe_timeout (10 s) all seven log Timed out. Forcing sync_state() and read state_synced = 1.
Next suspect: Omarchy's Snapdragon cmdline has clk_ignore_unused pd_ignore_unused, which keeps every clock and GDSC left on by firmware enabled forever. Testing without them comes after the long run.
This probably applies to every Snapdragon X laptop on current kernels, so the grep above is worth running on other machines.
Unrelated fix: my dell-7441-power-profiles.service from the earlier post was WantedBy=multi-user.target with After=power-profiles-daemon.service. PPD itself is After=multi-user.target, so this formed an ordering cycle and systemd silently dropped the service at every boot. It's now WantedBy=graphical.target.
Kernel 1.6: hardware video decode (iris), two sync_state blockers gone,
|
Speaker tuning v3: louder (the kernel caps speaker gain at -3 dB)After v2 the sound was balanced, but still clearly quieter than Windows: 30% there needed 60–70% here. Findings: Everything below the filter is already at maximum, apart from a deliberate kernel cap. The WSA884x PAs are at 6/6 (0 dB) and BOOST is on. The WSA RX digital volume sits at 81 (-3 dB). UCM's /*
* Set limit of -3 dB on Digital Volume and 0 dB on PA Volume
* to reduce the risk of speaker damage until we have active
* speaker protection in place.
*/
snd_soc_limit_volume(card, "WSA WSA_RX0 Digital Volume", 81);Windows has active speaker protection (the VI-sense feedback), so it can drive the same speakers harder. I've left the cap alone, since removing it needs a kernel patch and there's no speaker protection on Linux. The slider percentages aren't comparable either. PipeWire/Pulse volume is cubic (30% ≈ -31 dB, 60% ≈ -13 dB). Part of the "30% vs 65%" gap is the curve, not the output. v3 changes (the rest is as in v2): nodes = [
+ # 100 Hz high-pass first: the woofers can't reproduce sub-bass; removing it
+ # frees headroom for the compressor/limiter and reduces cone excursion.
+ { type = builtin name = hpL label = bq_highpass control = { "Freq" = 100.0 "Q" = 0.707 } }
+ { type = builtin name = hpR label = bq_highpass control = { "Freq" = 100.0 "Q" = 0.707 } }
...
- "Threshold level (dB)" = -24.0 "Ratio (1:n)" = 3.0 "Knee radius (dB)" = 6.0
- "Makeup gain (dB)" = 7.0 } }
+ "Threshold level (dB)" = -28.0 "Ratio (1:n)" = 4.0 "Knee radius (dB)" = 6.0
+ "Makeup gain (dB)" = 11.0 } }
...
- control = { "Input gain (dB)" = 0.0 "Limit (dB)" = -1.0 "Release time (s)" = 0.08 } }
+ control = { "Input gain (dB)" = 0.0 "Limit (dB)" = -0.5 "Release time (s)" = 0.08 } }
...
links = [
+ { output = "hpL:Out" input = "bassL:In" }
+ { output = "hpR:Out" input = "bassR:In" }
...
- inputs = [ "bassL:In" "bassR:In" ]
+ inputs = [ "hpL:In" "hpR:In" ]That's about +4 dB of perceived loudness at normal listening levels, while peaks stay capped by the limiter. Confirmed louder by ear. One pitfall: the raw ALSA speaker sink has to stay at 100%. PipeWire maps its volume onto the WSA884x PA gain (-9…0 dB), so if it's selected and turned down once (to 25%, say), the tuned output underneath gets ~7.5 dB quieter. I relabelled it with a WirePlumber rule ( |
Without
|
Speaker tuning v4: psychoacoustic bass (Calf Bass Enhancer)v3 was louder, but it sounded thin, "like a cheap earphone". Laptop woofers can't reproduce much below ~150 Hz, so v4 does what Windows audio packages do (MaxxBass-style virtual bass): it generates harmonics of the bass the speakers can't play, and the ear reconstructs the missing fundamental. The plugin is the Calf Bass Enhancer LV2 ( What worked and what didn't, measured with a 60 Hz test tone. I muted the raw ALSA sink and recorded its monitor, which is taken before the hardware volume:
Pitfall: the plugin's Final chain:
With the 60 Hz test tone: fundamental −21 dBFS, 120 Hz −25 dBFS, 180 Hz −26 dBFS. For A/B listening, the harmonics gain can be changed live, without restarting PipeWire: I keep a small Full
|
Correction:
|
What Ubuntu's X1 kernel adds, and what's worth taking (kernel 7.2.7-2.2)I was told the Ubuntu 7.2 ARM kernel has "many improvements for X1, including the NPU", so I went through Canonical's concept kernel: The claim doesn't hold up, at least for the kernel.
Taken:
I'll follow up once 7.2.7-2.2 has booted, with USB/NVMe/Wi-Fi checks and a suspend measurement. |
7.2.7-2.2 (QREF supplies) verified, plus an overnight suspend measurement: 0.93 WBoot: clean. NVMe, Wi-Fi, USB and PCIe all come up (these depend on the reference clocks, so they were the main risk). Suspend, overnight, charger unplugged: 7.49 h, 6960 mWh: That's 17.7% of the 39.42 Wh battery per 7.5 h night, or ~43 h of standby from full. It's the most precise figure so far. The earlier "~0.90 W" came from 17–29 min runs with +/-0.02–0.035 W error, so the QREF patch makes no measurable difference, as expected given the shared LDOs. So suspend stays at ~0.93 W, and the remaining blocker looks like firmware (the ADSP tick). The QREF patch stays in: it's upstream-bound and describes the hardware correctly. |
Correction: the Linaro
|
| kernel | run | suspend power | aosd/cxsd/ddr |
ADSP wakes |
|---|---|---|---|---|
7.2.7-2.2 |
overnight, 7.49 h | 0.926 W (±0.001) | 0 | 97.8/s |
7.2.7-2.3 = 2.2 + the two fixes |
32.5 min | 0.916 W (±0.018) | 0 | 97.9/s |
Equal within the gauge resolution, so the fixes cost nothing. They correct real bugs (workers touching I2C/Type-C hardware while their controllers are suspended), so they're now in this kernel as patch 0105. linux-msm's qcom-laptops-v7.2 tree carries them as c576458917 and 7106d100ce. My earlier warning against them was wrong, and my hypothesis about a DP path staying powered doesn't hold.
The deepest-idle series is effectively retested too: it's patch 0103 in this kernel, together with the 7.4 pmdomain backport, and suspend is at 0.93 W, not 1.74 W. Mainline 7.3 will get a fresh test when it's released and I rebase on it.
systemd 262 broke the AC-shutdown fix: hooks now get an empty argumentAfter today's update (systemd 261.3 → 262), the laptop again stayed on with the charger plugged in: screen off, keyboard backlight still lit. On its own everything still worked. The EC acted on a manual Finding out what happens after journald stops: the final shutdown stage isn't logged, and the screen shows nothing useful. EFI variables are writable on this machine (efivarfs via The hook is run by Fixes:
# /etc/systemd/system/dell-ec-standby-sleep.service
[Unit]
Description=Dell 7441: tell the EC about suspend (0xB9=1 before sleep, 0 after resume)
Before=sleep.target
StopWhenUnneeded=yes
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'b=$(basename "$(dirname "$(readlink -f /sys/bus/platform/devices/b94000.i2c/i2c-*/name)")" | sed s/i2c-//); [ -n "$b" ] && /usr/bin/i2ctransfer -y "$b" w64@0x3b 0xb9 0x01 0x00='
ExecStop=/bin/sh -c 'b=$(basename "$(dirname "$(readlink -f /sys/bus/platform/devices/b94000.i2c/i2c-*/name)")" | sed s/i2c-//); [ -n "$b" ] && /usr/bin/i2ctransfer -y "$b" w64@0x3b 0xb9 0x00 0x00='
[Install]
WantedBy=sleep.targetVerified: If you use Also today: the Omarchy update (r2304) overwrote the battery scripts again, so the bar lost the battery (it's |
Ambient light sensor works: automatic brightness via the ADSP sensor coreThis Inspiron has an ambient light sensor. Covering the top bezel dims the screen in Windows. On Snapdragon X it isn't a Linux device: it hangs off the ADSP's Qualcomm Sensor Core (SSC/SEE) on the DSP's own I2C bus. It's now working on Linux, with a small auto-brightness daemon on top. Credit to the Surface Pro 11 guide for the overall approach. The sensor: Stack:
Pitfalls, in the order I hit them:
Auto-brightness daemon: a ~250-line C program on libssc and GLib, run as a systemd user service:
Result: covering the sensor takes lux from ~36 to 0, and the target drops to ~10% within a few seconds, then recovers. It costs ~0.5% CPU and 9 MB RSS, survives cold boot and suspend/resume, and needs no kernel changes. Everything currently lives in a local build tree. I'm happy to share the hexagonrpcd patch and the daemon if anyone wants to try this on another X1 laptop, since the Windows files are per machine but the procedure should carry over. |
Update: charging icon fix, audio crackle fix, battery brightness curve, power profiles re-checkedStale charging icon (fixed with a udev rule). After unplugging USB-C, the bar kept showing the charging icon, and UPower's The icon now follows plug and unplug within a second or two. When plugging in, it may briefly show "not charging" while USB-PD negotiates; that state is real. The proper fix is a Occasional speaker crackle: rtkit was missing. PipeWire logged Auto-brightness now has a dimmer battery curve. It switches on battery status Power profiles re-checked from the bar buttons. Clicking power saver in the top bar applies CPU 2188 MHz / GPU 687 MHz within ~1 s, and balanced restores 3417 / 1250. A single-core Python loop took 1.66 s vs 1.10 s, which is about the ratio of the clock caps. So the caps really bite and don't just sit in sysfs. |
Webcam: factory colour matrices extracted from the Windows Chromatix fileThe Windows camera stack keeps Qualcomm's tuning for this exact sensor in the driver store:
libcamera's simple IPA accepts a list of CCMs keyed by Result: at full strength, objects and walls get noticeably truer colour than the by-eye tuning. Skin and greys pick up a green tint, and noise rises. The tint most likely comes from the simple IPA's grey-world AWB, since these matrices expect Qualcomm's AWB, and grey-world is fooled by strongly coloured walls. A 70 % factory / 30 % identity blend keeps most of the colour improvement with less tint and noise; that is what is installed now. The relay's Installed
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hardware results last updated 21 September 2026.
This discussion tracks Omarchy on my Dell Inspiron 14 Plus 7441, Snapdragon X1P-64-100 (X Plus). It covers results on this laptop, board-specific fixes, remaining limitations and ways to help test.
Shared installer and package dependencies, camera work, video decoding and power-management progress are tracked in Snapdragon X support #11823. This page records how those efforts land on the Inspiron rather than repeating their upstream status. The original installation account for this machine is in #7739.
What works on this Inspiron
rtkit: without it PipeWire runs non-realtime and occasionally crackles (details). See open issues.dp_aux_backlightregisters withmax_brightness: 0. Fixed by the board-specific device-tree change below; a patch is now submitted upstream and tested on this machine.0x3b, register0xB9= 1) from a systemd shutdown hook, as Windows firmware does (details). Since systemd 262 shutdown hooks get an empty argument; the hook no longer checks forpoweroffand suspend uses asleep.targetunit instead of asystem-sleephook (details).status,energy_nowandenergy_fullreport correctly. There is nocapacityattribute (the driver never registers it on this platform), but UPower computes the percentage correctly. Omarchy'somarchy-battery-status/-presentlook only forBAT*names; fix in #13029. Charger registers as USB-C PD (qcom-battmgr-usb), not Mains. Until that PR is merged, a local pacman hook re-applies the detection change after every Omarchy update. The kernel sends no uevent forqcom-battmgr-usbon plug/unplug, so UPower'sOnBatterygoes stale (wrong charging icon, no low-battery warning); a udev rule forwards the battery's event (details).power-profiles-daemonhas no backend here (PlatformDriver: placeholder), so switching alone does nothing. A small service applies frequency caps on each profile change: power-saver = CPU 2.19 GHz / GPU 687 MHz, balanced = full range (details).cpufreqpolicy: firmware reports a sustained frequency of 0 kHz for two of the three SCMI perf domains, so every OPP there is marked turbo and the policy is silently dropped. A one-function SCMIperf.cfix restores policies for all three clusters (details). Setschedutilwithcpufreq.default_governor=schedutilon the kernel command line.lm_sensors. The six fitted board thermistors (SYS_THERM1–6 on the PMK8550 ADC) are readable onceqcom-spmi-adc5-gen3and an ADC DT overlay are added; SYS_THERM7 isn't fitted (details).0xFB 0x20 <id> 0x02 <deci-°C>to I2C0x3b, as Windows' FECI driver and Linaro'sdell-xps-ecdo). A small service now reports the real board thermistors (falling back to the hottest SoC zone), and the fans are quiet and no longer react to short SoC spikes (board sensors) (details).v4l2*dec, mpvv4l2m2m-copy). NeedsCONFIG_VIDEO_QCOM_IRIS+CONFIG_SM_VIDEOCC_8550(both off in ALARM) and the Dell-signedqcvss8380.mbnfrom the Windows driver. 1080p H.264 at ~370 fps with ~6× less CPU than software (details).systemctl suspendentersdeepand resumes cleanly. Measured 1.141 +/- 0.017 W while suspended — about 34.5 h of standby, so an overnight lid-close costs ~23% of the battery. The SoC never reaches a chip-rail or DDR collapse; this is a known aarch64 Snapdragon limitation. On the patched7.2.6-1.4kernel with the EC standby hook: ~1.01–1.07 W over 43 min, no regression (details). Withfw_devlink.sync_state=timeout(interconnect/clock/RPMh providers otherwise keep boot-time max votes, because the GMU, iris and videocc never bind a driver): ~0.90 W over 29 min, and the CDSP now sleeps (details). See open issues.resume=setup is correct and the freeze/thaw stage passes, but writing the image hangs the machine (test_resume, forced power-off needed). Left disabled; use suspend (details).hexagonrpcd(patched for registry writes) serving the Windows pre-parsed sensor registry, pluslibssc; a small daemon adjusts brightness from lux, with a dimmer curve on battery (polls by re-enabling, sinceis_dri=0gives one sample per enable) (details).27c6:631c, USB. Works with stocklibfprint/fprintd— no kernel or device-tree work needed. Noteomarchy setup security fingerprintcurrently fails; see below.DP-1(DisplayPort alt-mode), its full mode list was read, and it ran as an extended desktop alongside the internal panel. No extra configuration needed.✅ Working in the tested setup.⚠️ Working with a fix, or limited. ❌ Not working. ❓ Untested — not a claim either way.
Results come from one machine in one configuration and do not imply availability in a released Omarchy image. Gaming, docks, Bluetooth audio quality and multi-monitor setups have not been tested.
Test configuration
06K61C2.16.0, dated 2026-07-097.2.6-1-aarch64-ARCHlinux-firmware-qcom 20260916-14.0.0.r2120.g66a33c3-1, edge channel,omarchy-devx1e80100-dell-inspiron-14-plus-7441.dtb, selected automatically from SMBIOS byDeviceTreeAutoin the UKI0x0ba4), 2560x1600Note on the kernel. All hardware results above were obtained on the stock ALARM
7.2.6-1kernel and apply to it. The machine currently runs a locally built7.2.6-2— the same source withCONFIG_DRM_DISPLAY_DP_AUX_CHARDEV=yadded, to validate PKGBUILDs#2225. The only behavioural difference is the presence of/dev/drm_dp_aux*; nothing else in this report depends on that build.Expected boot messages that are not errors. The device tree describes the board's full 12-core layout, but the X1P-64-100 is a 10-core part. Firmware correctly refuses the two cores that are not fused, so this is normal:
lscpuaccordingly showsOff-line CPU(s) list: 7,11. The SoC also reports as an X Elite family device in some places; that is cosmetic.Inspiron-specific fixes
Display brightness — PWM backlight (fixed)
By default this machine has no working brightness control at all, including the Fn keys (they are not an independent EC path — they run
omarchy-brightness-display→brightnessctl, which hits the same dead device):Why, confirmed from a probe-time capture on this machine (stock device tree,
drm.debug=0x106plus dynamic debug onpanel-edp.canddrm_dp_helper.c):The AUX read succeeds (
ret=5) — it is not empty and it is not misread.0x702 = 0x91advertises PWM brightness control and not AUX brightness setting, soaux_setstays false,drm_edp_backlight_probe_max()returns without populating max, andmax_brightnessis 0. That is the driver behaving correctly for a panel that says it is PWM-controlled.These bytes are identical to those captured independently on another 7441 by Avalon Vargas Centeno, so it is consistent across at least two units.
Two consequences. The panel is PWM-controlled by design, so this is not a kernel bug needing a quirk — the device tree was simply missing a description of the PWM backlight, which
panel-edpprefers over the AUX fallback whenever it is present. And nothing about the AUX path is worth "fixing": an earlier theory on this hardware, that thevreg_edp_3p3regulator was being power-gated before the capability read, was tested withregulator-always-onand made no difference — consistent with a read that was succeeding all along.The state is unchanged across suspend/resume, and no backlight re-probe happens on resume.
Comparing the Snapdragon X device trees shipped in
linux-aarch64makes the pattern clear:x1e78100-lenovo-thinkpad-t14sedp-panelx1e80100-hp-omnibook-x14edp-panelx1e80100-lenovo-yoga-slim7xsamsung,atna45dc02(dedicated driver)x1e80100-dell-inspiron-14-plus-7441edp-panelx1e80100-dell-latitude-7455edp-panelx1e80100-dell-xps13-9345edp-panelEvery board with working backlight on a generic
edp-panelprovides a DT PWM node. The hardware is already present on the Inspiron —pmk8550_pwmexists but shipsstatus = "disabled"with nothing wired to it.The fix wires it up the same way the T14s and HP Omnibook do. It follows Avalon Vargas Centeno's dri-devel RFC; Val Packett's reply in that thread explains the
panel-edpprecedence that makes it work.Upstream status: Avalon has submitted this as a patch to
arch/arm64/boot/dts/qcom/x1e80100-dell-inspiron-14-plus-7441.dts— "arm64: dts: qcom: Fix backlight control on Dell Inspiron 7441", carrying aFixes:tag against the commit that added 7441/Latitude 7455 support. I tested the patch as submitted on this machine and it is creditedReported-by:andTested-by:.Verified on the patch version (confirmed live via
num-interpolated-steps = <10>in/sys/firmware/devicetree/base/backlight/, distinguishing it from the local overlay below):max_brightness: 100,dp_aux_backlightgonedeepis clean, brightness still working afterwardsOnce the patch reaches a released kernel, the shipped DTB will already contain the
/backlightnode and the local workaround below becomes unnecessary. The re-apply hook described further down checks for that node before acting, so it degrades to a no-op rather than conflicting.The patch differs from the overlay below only in the brightness table: 11 anchors with
num-interpolated-steps = <10>instead of 101 explicit values. Both yield the same 101 effective levels, and both behaved identically here.Overlay (
dell-7441-pwm-backlight.dtso):Apply it:
After reboot:
dp_aux_backlightdisappears entirely once the DT backlight exists. Fn brightness keys and the Omarchy bar slider both work with no further configuration.Two caveats. The PWM period is discussed below — it was inherited rather than measured. And
/boot/dtbs/qcom/*.dtbis owned bylinux-aarch64, so a kernel upgrade reverts it; a pacman hook that re-applies the overlay before the UKI is rebuilt is in the step-by-step writeup, along with a method for testing it on a throwaway boot entry first.On the PWM frequency. The period above is
500000ns — 2 kHz. It did notstart that way. The overlay originally used
4266537ns (234 Hz), copiedverbatim from
x1e78100-lenovo-thinkpad-t14s, because that was the nearestworking example; nothing about it was measured for this panel.
234 Hz is low enough to matter. Flicker is worst at low brightness, where the
duty cycle is shortest: at 20/100 the backlight is fully dark for roughly
3.4 ms out of every 4.3 ms. Nothing in the hardware requires that, though —
checking every device tree shipped in
linux-aarch64shows the same QualcommLPG PWM running far faster elsewhere:
x1e78100-lenovo-thinkpad-t14sx1e80100-hp-omnibook-x14,-elitebook-ultra-g1qx1e80100-microsoft-romulus13/-15sc8280xp-lenovo-thinkpad-x13s,sc8180x-primusx1p42100-lenovo-thinkbook-16x1p42100-asus-zenbook-a14-lcdsc7280-herobrine-crdSo the 200–234 Hz cluster is what the earlier ports happened to use, not a
limit. This board now uses the ThinkBook 16's value. Verified after reboot:
/proc/device-tree/backlight/pwmsreads500000, and brightness trackscorrectly across the full range, 1 through 100 — the failure mode to watch for
is an LED driver that cannot follow a faster PWM input, which would show up as
brightness sticking or dropping out at the low end.
This is still not a measurement of this panel. It is a precedented value on the
same PMIC rather than one borrowed from different hardware, which is a smaller
claim than it may look. Worth noting for context: NotebookCheck's review of the
Dell Latitude 7440, whose AUO B140QAX panel is the same family as this one
(
AUO B140QAX01.H), reports "screen flickering / PWM not detected" — so thereis no panel-side reason to run the backlight slowly.
If a future kernel ships a Dell-specific backlight node upstream, its value
should be preferred over this one.
That hook has since been confirmed working through a real kernel upgrade. Installing a locally built
7.2.6-2replaced the packaged DTB with the stock one, the hook re-applied the overlay before90-mkinitcpio-installrebuilt the UKI, and brightness was unaffected across the reboot. Verify after any kernel update with:fdtget /boot/dtbs/qcom/x1e80100-dell-inspiron-14-plus-7441.dtb /backlight compatible # -> pwm-backlightCPU frequency scaling
Without a governor setting, the machine boots with the
performancegovernor and nothing ever scales it down, becausepower-profiles-daemondoes not manage scaling here. Switching toschedutilnoticeably helps battery life with no perceptible loss under load. The Omarchy ISO's platform entry now sets it at boot withcpufreq.default_governor=schedutilon the kernel command line; to switch by hand:conservative ondemand userspace powersave performance schedutilare all available.Two limitations worth knowing:
Only CPUs 0–3 are under frequency control on a stock kernel. Fixed with a
kernel patch (full write-up). A stock kernel creates a single
policy0(driver
scmi, 710400–3417600 kHz across 13 steps) covering CPUs 0–3. The othersix online cores get no
cpufreqinterface at all, so the governor controlsless than half the chip.
Cause: firmware reports a zero sustained frequency
scmi_cpufreq_init()succeeds for every cluster up to the frequency tablecheck, and
cpufreq_table_validate_and_sort()then returns-EINVALsilentlyfor clusters 1 and 2. An earlier revision of this page blamed missing OPP
tables for cpu4 and above in
/sys/kernel/debug/opp/. That was a symptom: thedriver registers all 13 OPPs and removes them again once the table is rejected.
The real cause is in SCMI
perf.c, which marks every OPP above the domain'ssustained frequency as turbo:
The X1P-64-100 firmware reports
sustained_freq_khz = 0for perf domains 1 and2 (NCC1, NCC2). Every OPP of those clusters becomes a boost frequency, and a new
policy is validated before boost is enabled for it, so no usable frequency is
left. A kprobe on
dev_pm_opp_add_dynamic()showsturbo=1on all 13 OPPs ofcpu4 and cpu7, followed by
ret=-22. The instructions are in the linkedcomment and need no rebuild.
The fix ignores a sustained frequency below the domain's lowest OPP. With it,
all three clusters get a policy (
policy0for 0–3,policy4for 4–6,policy7for 7–9), and the boot log records the firmware values:Nothing in mainline 7.3, linux-next or Ubuntu's
linux-qcom-x1etouches thiscode, so this likely affects every X1P-64-100.
A related device-tree fix, worth applying on its own
This is a 10-core X1P-64-100 described by the 12-core die's device tree, so
CPU7 and CPU11 (
cpu@10300,cpu@20300) are fused off:They were also being counted in the SCMI sharing masks (
4-7,8-11). Markingthose two nodes
status = "fail"gives a clean boot — all cores online as 0–9,no PSCI failures, masks
0-3/4-6/7-9:Use
fail, notdisabled: arm64 CPU enumeration skips onlyfail/fail-(
__of_device_is_fail()indrivers/of/base.c), because for CPUsdisabledlegitimately means "present but not yet started". This does not create the
missing policies — it was tried as a fix for them and did not work — but it is
a correctness improvement in its own right. The cpufreq fix is the SCMI change above.
Useful technique
No rebuild is needed to investigate this further.
CONFIG_DYNAMIC_DEBUG=y, soecho 'file drivers/cpufreq/cpufreq.c +p' > /sys/kernel/debug/dynamic_debug/controlturns on the core's tracing, and offlining then onlining a CPU of an affected
cluster re-runs
cpufreq_online()without rebooting.cpufreq_policy_init_qosis inlined — probe
freq_qos_add_requestinstead.Power profiles do nothing.
power-profiles-daemonoffers onlypower-saverandbalanced(noperformance), and switching between them changes neither the governor norscaling_max_freq:So
omarchy powerprofiles set battery power-saverwill record the preference and apply a profile with no effect. On this machine the cpufreq governor is the only working lever. Whetherpower-profiles-daemonshould gain a backend for this SoC is a question for the shared tracker.Update: made functional (details). With cpufreq on all 10 cores (SCMI
fix), a service watches PPD's
ActiveProfileover D-Bus and applies caps:power-saver limits every cluster to 2188.8 MHz and the GPU to 687 MHz, and
balanced restores the full range. The top bar,
powerprofilesctland Omarchy'sAC/battery switching now have a real effect.
Open issues
Shutdown with the charger attached (fixed with an EC hook)
Fixed on this machine (full write-up). The embedded controller was
never told the system was going down. On Windows, the
PEP0LPS0_DSM(Microsoft Modern Standby UUID
11e00d56-…) writes EC register0xB9= 1on standby entry and
0on exit. The EC is at I2C address0x3bon DTi2c5(
\_SB.I2C6,QUP_0_SE_5,0xB94000, 100 kHz), which the Dell device treeonly mentions in a comment. Linux never sent this, so with AC attached the EC
kept the hardware powered. Two small systemd hooks, a
system-shutdownone(power-off only) and a
system-sleepone (1 before suspend, 0 after resume),now write it. Shutdown on AC then powers off exactly like on battery, and in
suspend the keyboard backlight goes dark together with the screen. Not yet
tested: whether it also works with
i2c5left at the DT's 400 kHz (I switchedit to the 100 kHz the DSDT asks for).
Same EC as the Dell XPS 13 9345 (details). Linaro's
dell-xps-ecdriver (branch
arm64-laptops-v7.3-rc1-camss-v13) targets the same address,bus and speed (
0x3b,i2c5, 100 kHz) and the same0xB9command, sent as one64-byte write. The hooks now send that exact form. The 64-byte standby state
survives power-off, so a boot-time
dell-ec-resume.servicesends0xB9= 0 atevery start; without it, the keyboard backlight stays dark after a shutdown.
With an Inspiron compatible string and an optional IRQ (the Inspiron DSDT has
none),
dell-xps-ecshould cover this machine too. The driver also reportsboard temperatures to the EC every 100 ms, which nothing does here yet.
The investigation that led there, kept for reference:
systemctl poweroffbrings the system down but the hardware stays powered — fans keep spinning, keyboard backlight stays lit and responds to keypresses, and a short power-button press reboots the machine. Unplugging the charger powers it off immediately. On battery it powers off normally.An earlier revision of this page claimed the deciding factor was active charging rather than mere charger presence, on the basis of one apparently successful shutdown with a full battery. That observation was mistaken — it was a shortened screen-blank timeout being read as a successful power-off. The charger being attached is the only established factor, and charge state does not appear to matter.
Ruled out so far:
systemctl poweroff -ffbypasses the shutdown sequence entirely — still hangspon@1300is byte-identical tox1e78100-lenovo-thinkpad-t14s; it comes from the shared SoC.dtsi, so there is nothing board-specific to changePSCI itself is healthy (
PSCIv1.1, andSYSTEM_RESETworks — reboots are fine). The PMIC PON block (qcom,pmk8350-pon) only instantiatespwrkeyand a disabledresin, registering no power-off handler, so there is no PMIC fallback. Charger and battery state on this platform are owned by firmware on the ADSP and relayed overpmic_glink— consistent with the several-second lag before the battery indicator updates after plugging in.There is an analogous upstream case on Pixel C, where PSCI is advertised but
SYSTEM_OFFis non-functional and shutdown is performed through the PMIC instead (power: sys-off series).Old workaround, before the EC hook: shut down and then unplug. It powered off the instant the plug came out.
Has anyone seen this on another Snapdragon X laptop? Since the PON node is shared SoC-level, this may not be Dell-specific. If you have a Yoga Slim 7x, T14s, Omnibook X14 or similar: does
systemctl poweroffactually cut power with the charger plugged in? Watch the fans and keyboard backlight rather than the screen — a blanked display is easily mistaken for a completed shutdown.Battery percentage (resolved)
/sys/class/power_supply/qcom-battmgr-bat/capacitydoes not exist. That is nota firmware problem: on the sc8280xp/x1e code path
qcom_battmgrnever registersPOWER_SUPPLY_PROP_CAPACITY. UPower computes the percentage correctly fromenergy_now/energy_full, the same way Ubuntu gets it. In Omarchy, the bar canshow it with
"showPercentage": trueonomarchy.power(or with a right-clickon the icon). The power panel showed "—" because
omarchy-battery-statusandomarchy-battery-presentonly look forBAT*names; fixed in#13029. Details are in
this comment.
Internal speakers — image pulls right, and no speaker tuning
Update: Windows sounds louder mostly because of its DSP processing. The
volume slider drives the amplifiers' own gain (WSA884x
Speakers Volume,-9…0 dB), so at 50% they sit at -7.5 dB, and Linux adds no loudness
processing. A PipeWire
filter-chainsink with EQ, a -4.5 dB right-channelcorrection and a compressor + limiter gets close. The config is in
this comment. Mind the lack of speaker protection on Linux.
v2 (config) adds more presence (+4 dB @ 3 kHz, +2.5 dB shelf
Sound works out of the box. Two things are still wrong next to Windows on the
same machine, and the second has no Linux-side cause.
The four amplifiers are presented as 4.0 surround. The board carries four
WSA884x smart amplifiers, two per side. Verified by injecting a tone into one
channel at a time and listening: ch0 left, ch1 right, ch2 left, ch3 right. The
device tree agrees:
alsa-ucm-confexposes them as a bare 4-channel PCM (PlaybackChannels 4) withno way to describe what those channels physically are, so PipeWire applies its
default 4-channel layout —
FL, FR, RL, RR— and treats a two-way stereospeaker system as a surround system. Channels 2 and 3 are the second driver of
each side, centimetres from the first, but being labelled RL/RR they get
PipeWire's rear-channel treatment:
A WirePlumber drop-in disables both:
Do not "fix" this by relabelling the channels
FL, FR, FL, FR. It is theobvious move and it is wrong: PipeWire's mixer maps an input position to a
single output, so with duplicate positions the second occurrence wins and the
woofers fall silent. Measured +9.5 dB at 5 kHz and −22 dB at 200 Hz.
A UCM
SplitPCMoverride does not help either. It builds adsharePCM with1:1
bindings, so it splits a multichannel device into subsets and cannotduplicate one input channel to two outputs.
The stereo image pulls right, and that part is not software. Measured with
the internal microphone, full-range multitone, stereo left-only versus
right-only at matched volume: the right side is roughly 6 dB louder, and it is
clearly audible. Everything on the Linux side is symmetric:
[1 2 3 7 10 13], tweeters[4 5 6 7 11 13]Windows images this machine centrally on the same hardware, so the chassis is
acoustically asymmetric and the vendor DSP compensates. That is the substance of
"Windows sounds better" on this laptop — not a missing driver, but missing
tuning.
It can be compensated with a PipeWire filter-chain gain trim, but the right side
already sits at maximum gain, so centring the image costs 1.5–3 dB of loudness.
Doing it in hardware instead does not work: sweeping the
WSA2macro digitalvolume from 81 down to 61 changes the output by nothing measurable, so those
controls are not in the active gain path on this topology.
The profile is inherited.
x1e80100.confselects by regex:so the Inspiron 7441 runs the Latitude 7455's profile, and its channel layout
has never been verified for this model specifically.
The DSP topology is inherited too, and carries no tuning. Unlike the HP
machines documented in
omarchy-snapdragon, which fail
to register an ALSA card at all for want of a topology, this board has one in
linux-firmware:It is byte-identical to the Latitude 7455's — both 24,704 bytes, MD5
8def569eb6b52124f901d8135fc7c823. Upstream builds the two from one source:so this machine is treated as a Latitude 7455 at both levels — UCM profile and
DSP topology.
More to the point, no x1e80100 topology contains any speaker tuning at all.
Scanning all fifteen shipped for this SoC for EQ, IIR/FIR, DRC/MBDRC, limiter,
crossover and speaker-protection modules returns nothing on every machine —
ASUS, HP, Lenovo, Microsoft, TUXEDO and Dell alike. The Inspiron topology
declares exactly two named controls:
These are routing graphs, not tuned ones. The crossover, EQ, bass management and
speaker protection a Windows install applies are not present anywhere in the
Linux stack for this hardware. There is no better file to install and no switch
to enable: the tuning does not exist yet, for any of these laptops. Producing it
is measurement work rather than a code change, and a laptop's internal
microphone is not adequate for it — repeat measurements here varied by about
±1.5 dB, enough to make a plausible-looking crossover sound clearly worse than
no crossover at all.
A caution on method, since these are small differences: the measurements above
come from the internal microphone, which repeats to about ±1.5 dB. The
structural findings — the channel order, the symmetric configuration, the 4.0
misinterpretation — are solid and were each confirmed from more than one source.
The individual decibel figures are indicative, not tuning-grade, and listening
overruled them more than once.
Webcam
No
/dev/video*or/dev/media*device is created on a stock kernel. Camera work for this SoC family is tracked in #11823; what follows is only the Inspiron-specific part.With the in-review upstream series applied (see Tested with the upstream series below) the camera works end to end — raw capture at 30 fps, and, with the software ISP and loopback hop described below, an ordinary
Integrated Camerathat Chromium streams at a sustained 29.9 fps.Sensors identified, read out of the Windows driver store on this machine (read-only mount,
C:\Windows\System32\DriverStore\FileRepository\):com.qti.sensormodule.ov02e10.bininqccamfrontsensor_extension8380com.qti.sensormodule.hm1092.bininqccamauxsensor_extension8380The front module is a LuxVision assembly with an M24C64-series EEPROM. The HM1092 is most likely the IR/presence sensor used by Windows Hello. The driver INFs themselves only name Qualcomm's generic shim ("Qualcomm(R) Spectra(TM) 695 ISP Camera Front Sensor Device"), so the sensor identity comes from the
com.qti.sensormodule.*blob names rather than the INF.Driver situation is better than the missing device suggests. No sensor driver needs writing:
Mainline has an
ov02e10driver; the ALARM kernel simply does not enable it. CAMSS is available as a module.CONFIG_VIDEO_OV02E10is now proposed for ALARM in PKGBUILDs#2226, validated by a clean-chroot build containingov02e10.ko.The actual blocker is the device tree, and it is not Dell-specific. No board device tree shipped in
linux-aarch64describes the camera subsystem at all — checking everyx1e80100-*andx1p42100-*DTB in the package finds nocamss,cciorcsiphynode on any of them, including the Lenovo Yoga Slim 7x, whose camera is known to work. That work therefore runs on out-of-tree device-tree patches rather than anything shipped.For this board specifically, the DT contains only the camera's supporting cast:
So the hardware is acknowledged but never described. Three things would be needed, in order:
CONFIG_VIDEO_OV02E10— a one-line config change, necessary but not sufficient. Proposed in PKGBUILDs#2226.camss/cci/csiphynodes forx1e80100, absent from every shipped board DT in this kernel. Since the Yoga's working camera implies such nodes exist out of tree, the practical question is whether they are reusable as-is or entangled with board-specific wiring.ov02e10node: I2C slave address, regulators, GPIOs, clocks and CSI lane assignment. The Windows sensor blob contains exactly these fields (sensorSlaveAddress,laneAssign,i2cFrequencyMode,eepromSlaveAddress) but as binary values, so they need extracting or probing.Worth noting the Yoga Slim 7x uses the OV02C10, a sibling of this sensor, and its driver is already enabled in ALARM as a result of the camera work tracked in #11823. That work is the natural template here rather than starting from scratch.
For contrast, the Surface Pro 11 project has cameras working on the same SoC, but by a much heavier route — independently authored IMX681/OV13858 drivers plus board-specific C-PHY initialisation transcribed from runtime WinDbg MMIO observation, carried on a custom kernel branch. That approach is not needed here, since the OV02E10 driver already exists upstream.
Tested with the upstream series
Bryan O'Donoghue's in-review series includes a patch for this exact board — "arm64: dts: qcom: x1e80100-dell-inspiron14-7441: Switch on CAMSS RGB sensor", which supplies the complete board wiring (sensor at CCI1
0x10, CSIPHY4, lanes 1–2,CAM_CC_MCLK4_CLKat 19.2 MHz, reset GPIO 237, and thevreg_l7b_2p8/vreg_cam_1p8supplies).The camera works with the full stack built on top of Linux 7.2.6 (Arch Linux ARM):
x1e-csi2-phyv17 (20260903-x1e-csi2-phy-v17)20260903-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v14)884565dd— "media: qcom: camss: Use data-lanes starting at 1 for new CSIPHY mode"CONFIG_VIDEO_OV02E10=m(PKGBUILDs#2226)All 20 patches apply cleanly to 7.2.6.
Capture result:
Sustained 30 fps at the expected frame size for 1928×1088 packed 10-bit Bayer. The frames contain real sensor data rather than a static buffer — roughly 1.55 MB of each 2.63 MB frame differs from the next, with an intensity distribution consistent with a dimly lit room. Also enumerating correctly:
qcom-mipi-csi2-phybinds toacec000.phy,ov02e10binds at i2c6-0010reportingSGRBG10_1X10 1928x1088with an exposure range of 1–2242 read from the hardware, and the media graph links"ov02e10 6-0010":0 -> "msm_csiphy4":0 [ENABLED,IMMUTABLE].The lane normalisation commit is essential and easy to miss. Without
884565dd, everything above enumerates identically — the PHY binds, the sensor responds, libcamera lists the camera — but streaming silently produces no frames, with no CAMSS, CSID, VFE or CSIPHY message indmesgand the camera regulators never leavingdisabled/users=0. The cause is that CSID consumesdata-lanesdirectly, so the v6 device tree'sdata-lanes = <1 2>made it enable lanes 1 and 2 instead of 0 and 1. That commit is dated 18 September, two days after the v14 series, so a stack assembled from the series alone will not contain it.This is still an in-review stack, not something a stock Omarchy install has.
Getting from raw frames to a camera applications can use
A working CAMSS pipeline is not yet a webcam. It delivers multiplanar raw Bayer requiring Media Controller setup, while browsers look for a single-planar YUV device, so nothing sees a camera until two more pieces are in place.
1. Let libcamera's software ISP run. It debayers raw Bayer into RGB, but needs DMA-BUF heaps, which are root-only by default:
/etc/udev/rules.d/99-dma-heap.rules, plus adding your user tovideoand starting a new session:uaccessdoes not work here —dma_heapdevices are virtual and seatless, so logind never applies an ACL. With access granted,cam -c1 --infochanges from offering onlySGRBG10_CSI2P/RAWtoABGR8888/sRGBat resolutions from 160×120 to 1920×1080, debayered on the Adreno GPU.2. Convert to YUYV through a loopback device. libcamera's V4L2 compatibility shim (
libcamerify) exposes only 32-bit RGB —AB24,XB24,AR24,XR24— and Chromium's V4L2 capture path accepts none of them, so it still reports no camera. The fix is a conversion hop intov4l2loopback, which Omarchy'sv4l2-relaydpackage manages:Set
VIDEOSRCand aCARD_LABELin/etc/default/v4l2-relayd.VIDEOSRCmust carry the conversion elements itself —v4l2-relaydappends! appsink caps=…to whatever you give it, with nothing in between, so a barelibcamerasrcasks libcamera's software ISP to emit YUY2 1280×720 straight from the sensor's 1928×1088 SGRBG10. That negotiates successfully and then crawls:Create a matching module option so the loopback is named identically:
max_buffers=8is not cosmetic. At the module default of 2, GStreamer'sv4l2sinkfails immediately after the first frame withgst_v4l2_allocator_dqbuf: buffer 1 was not queued, this indicate a driver bug, which wedges the output pipeline — one frame, then nothing.Add any file under
/etc/v4l2-relayd.d/(e.g.camera.conf) so the systemd generator creates an instance. The instance matches its loopback device by label, so the two must agree.3. Give the service a dma-buf heap — and only the system one. The udev rule in step 1 covers interactive use, but the service is sandboxed.
v4l2-relayd@.serviceships with:an allow-list written for Intel IPU6/IPU7 laptops, which have a hardware ISP and never touch
/dev/dma_heap.DevicePolicy=closedis a cgroup device filter, so root does not bypass it — the software ISP is disabled inside the service even though the identical pipeline works from a shell, and the loopback carries undebayered data, i.e. a black picture. Add a drop-in:Naming the system heap explicitly is deliberate.
DeviceAllow=char-dma_heap rwalso lets the ISP start, and is a trap: libcamera probes/dev/dma_heap/linux,cmabefore/dev/dma_heap/system, so whenever the CMA heap is reachable it wins — and this board reserves only 128 MiB of CMA, shared with the display. That survives the first few capture cycles and then fragments:Roughly 8 MiB contiguous is requested while the pool holds only 16- and 23-page slivers plus one 5.3 MiB chunk, so allocation returns
-EBUSYand the stream goes back to black — withCmaFreestill reporting tens of megabytes, because the space is shredded rather than used. It is the classic "worked when I tested it, black an hour later", and it is why this needs testing over repeated open/close cycles rather than once. Hiding the CMA heap makes libcamera fall back to the system heap, which is ordinary scattered pages; the soft-ISP buffers are CPU-mapped and need no physical contiguity. With the drop-in in placeCmaFreedoes not move at all during capture.Then
systemctl enable --now v4l2-relayd.Chromium then sees an ordinary
Integrated Camera, at a sustained 29.9 fps measured at the loopback (1197 frames in 40.0 s), holding across repeated open/close cycles.v4l2-relaydstarts the source only when an application opens the device, so the sensor and its privacy LED stay off when idle — 0.00% CPU and all four camera regulators atdisabled/users=0between uses — unlike running agst-launchpipeline permanently.One cosmetic artefact remains: the first frame of each session is
v4l2-relayd's built-in splash, a uniform black frame, before it switches to the camera.Two of these are not Inspiron-specific and are worth fixing at the source:
v4l2-relayddevice allow-list is Intel-only, so the libcamera software ISP can never start under the service on any Qualcomm machine. That is a packaging bug, not a configuration choice.DmaBufAllocatorpreferringlinux,cmaoversystemunconditionally is the wrong default on boards with a small CMA pool shared with the display.DKMS needs kernel headers matching the running kernel, which for a locally built kernel means installing the
linux-aarch64-headerspackage from the same build.Image quality is uncalibrated. libcamera has no tuning data for this sensor:
so colour and exposure are approximate. Adding an
ov02e10entry to libcamera's sensor properties database and a tuning file would be a separate, self-contained contribution.Update: tuned by hand (details). Three things fixed the picture
browsers get:
/etc/libcamera/ipa/simple/ov02e10.yamlwith a diagonal CCM(0.90, 0.90, 1.18)counters the simple AWB's yellow-green cast. The AWB ignores
awb-enable/colour-gains, and the CCM is also what makesSaturationwork.libcamerasrc: the default 1080p → YUY2 →downscale path lost ~40% saturation.
saturation=1.6 contrast=1.1 gamma=2.6.The privacy LED (
led-camera-indicator, GPIO 110) can be driven by V4L2 itselfby adding
leds/led-names = "privacy"to the sensor node.Two notes for anyone reproducing this:
Depends-onlinks from older revisions alongside the current one. Following the v9 PHY link from the v4 entry fails at probe withRequired OPPs not available→Failed to attach power-domain list→-EINVAL, because that July driver expects OPP tables and power domains the September device tree dropped. v17 is the one that matches.x1-dell-thena.dtsi, whichx1e80100-dell-latitude-7455.dtsalso includes — so it enables CAMSS on the Latitude 7455 too, although the commit log mentions only the Inspiron.Fingerprint reader (works, but the setup command fails)
The reader is a Goodix
27c6:631con USB, and the kernel sees it out of the box:Nothing kernel-side is required — fingerprint readers are driven in userspace, so unlike the camera this needs no device-tree or driver work. Stock
libfprintdrives it through thegoodixmocdriver:Enrol and verify with
sudo fprintd-enroll $USERthenfprintd-verify.omarchy setup security fingerprintdoes not complete on this machine. It aborts at its package-install step:libfprint-gitis not present in theomarchyrepo (checked on the edge channel, aarch64), and the script usesset -e, so it exits before enrolling or configuring PAM. The script's comment explains the intent — "libfprint-git tracks upstream ahead of the Arch release, so a new reader only needs a pin bump in omarchy-pkgs" — but for this reader the hard dependency is unnecessary: stocklibfprint 1.94.100drives it. I have not established whether x86 installs are affected too.Until that is fixed, the setup can be completed by hand. Enrol first, verify, and only then edit PAM — that ordering is the script's own safeguard, since detection proves a reader exists but not that libfprint can drive it. The script adds
pam_fprintdassufficient(so password remains the fallback) preceded by a clamshell gate, which skips fingerprint when the lid is shut rather than blocking on an unreachable reader:Those two lines go at the top of
/etc/pam.d/sudoand/etc/pam.d/polkit-1, plus a/etc/pam.d/omarchy-lock-fingerprintstack for the lock screen.Scope: this covers
sudo, polkit prompts and the lock screen. Login at the SDDM greeter stays password-only.Do not add
pam_fprintdto/etc/pam.d/sddm. I tried it, and it makes login worse rather than better: SDDM's greeter gives no visual prompt for the sensor, sopam_fprintdblocks silently. You type your password, nothing appears to happen, and login only proceeds once you happen to touch the reader — effectively demanding both factors with no indication why. Omarchy's setup script leaving the greeter alone is a deliberate decision, not an oversight. Reverting is simply removing the two lines again.Note
/etc/pam.d/sudois package-owned, so updates can overwrite it — worth keeping a copy and checking withgrep -c pam_fprintd /etc/pam.d/{sudo,polkit-1}afterwards.Cosmetic: tools report the wrong CPU
Both btop and fastfetch name this CPU incorrectly, for two different reasons. Neither is a hardware or detection failure, and neither affects anything functional — but both look like bugs, so they are worth knowing about.
btop (Omarchy's
SUPER + CTRL + T"Activity" binding) shows a generic or wrong CPU because on aarch64/proc/cpuinfopublishes nomodel namefield at all, only numeric identity:lscpumaps those through its own ARM part table toQualcomm/Oryon; btop has no such table. Set an override in~/.config/btop/btop.conf:btop also shows 12 cores, two of them permanently offline — expected on this 10-core part, as described above. On a stock kernel, per-core frequency readings come only from CPUs 0–3, for the
cpufreqreason above; with the SCMI fix, all ten cores report.fastfetch reports
Qualcomm Snapdragon X Elite X1E-80-100 (4) @ 3.42 GHz, which is wrong twice over. The name comes from the device-tree compatible string:The board's device tree genuinely uses the
x1e80100SoC ID, so fastfetch faithfully reports an X Elite part number for what is actually an X1P-64-100 (X Plus). On a stock kernel the core count comes back as(4)rather than 10, becauseshowPeCoreCountgroups by frequency and sees only the singlecpufreqpolicy. With the SCMI fix it reports(10).fastfetch does not merge configuration files, so overriding means copying the whole config and editing the
cpumodule:Then replace
"showPeCoreCount": true,in thecpumodule with:which gives
Qualcomm Snapdragon X1P-64-100 (Oryon) (10) @ 3.42 GHz. Note the copy will not pick up later changes to Omarchy's default config; delete it to go back. Also note thatfastfetch --structure CPUbypasses the config file, so it still prints the old string — check with a plainfastfetch.Suspend power: 1.14 W, and the SoC never deep-sleeps
Measured, charger unplugged,
mem_sleep=deep, over 35.8 minutes:That is 34.5 hours of standby from the 39.42 Wh battery — closing the lid
overnight costs about 23% of the charge. Method: a
systemd-sleephook recordsenergy_nowat both boundaries.rtcwakecannot auto-wake this machine(
rtc0has nowakealarm), so runs have to be ended by hand.Two artefacts make short sleeps useless, and the second is the larger:
independent of sleep length, which is amortised away only over a long sleep.
Measured on this machine, same kernel, varying only the duration:
So only runs of ~30 minutes or more are meaningful, and two figures may only be
compared if their durations are similar. Subtract 24000 uWh before dividing by
hours if a shorter run must be used. Every figure below is from a run of 33
minutes or longer unless stated.
The cause: the SoC never performs a low-power collapse. From
/sys/kernel/debug/qcom_stats(needsCONFIG_QCOM_STATS, root):aosdcxsdddrapssadspZero since boot, including across measured suspends. The subsystems sleep; the
SoC as a whole does not. The instrument is validated: the
ddr_statstablein the same mapped SRAM region contains firmware-written content (the DDR
frequency list, 200 MHz through 3187 MHz, with CP indices), so the region is
live and the zeros are real rather than an unpopulated counter.
This is a known platform limitation, not an Inspiron fault. The
aarch64-laptops hardware matrix records
for Snapdragon X machines, including the Dell XPS 13 9345:
That page cites 6.13-rc1 kernels; the measurements below independently confirm
the limitation still holds on 7.3-rc4.
What helped: forcing
sync_state()Seven providers (four interconnects, gcc, gpucc and
qcom-rpmhpd) never runsync_state()and keep their boot-time maximum votes, because three consumers never bind a driver:3d6a000.gmu,aa00000.video-codec(iris,CONFIG_VIDEO_QCOM_IRISoff) andaaf0000.clock-controller(videocc,CONFIG_SM_VIDEOCC_8550off). Check withjournalctl -k -b | grep 'sync_state() pending'. Forcing it (printf 1 > …/state_synced, orfw_devlink.sync_state=timeouton the cmdline) brings suspend to ~0.90 W and lets the CDSP sleep, butcxsd/ddrstay at 0. Credit to Jim Martin (Dragon group) for the lead (details). Since kernel1.6iris and videocc bind, so the interconnects andqcom-rpmhpdsync by themselves; only gcc/gpucc still wait for the GMU (details).What was tried, and did not work
aosd/cxsd/ddrpmdomain/cpuidle-pscibackport + 7.3 PDC/domain_ss3seriesThe 7.3-rc4 run is only 13.9 minutes, so its figure is the least trustworthy of
the first four. The two 7.2.6-1.4 runs are short and include about a minute awake, so
they only show that
cxsdstays at 0. With thepmdomainbackport thefused-core clusters no longer block their parent, and
power-domain-systemnow enters SS3 at idle and in suspend, yet CX still doesn't collapse. The
CDSP never enters sleep on any kernel, but stopping it made no difference. The
ADSP enters and leaves sleep about 100 times a second, at idle as well as in
suspend. Every Linux client of the ADSP was ruled out: PipeWire, the sound card,
the battery/UCSI clients, and all ADSP audio drivers kept from loading at boot.
The rate stayed at 96–98/s, so the tick is internal to the ADSP firmware
(details). With the EC standby hook, a 43-minute run measured
~1.01–1.07 W (details). That matches or slightly beats the stock
baseline, so unlike the earlier variants this combination costs nothing, but
cxsdstill stays at 0.The upstream series "x1e80100: Enable PDC wake GPIOs and deepest idle
state"
(Maulik Shah, merged for 7.3) adds the SoC-deepest state
domain_ss3andcorrects
cluster_cl5's latencies. Backporting all eight of its commits to7.2.6 applies cleanly and builds, but makes suspend worse. Mainline 7.3-rc4,
where the whole series is native and in context, is also worse than 7.2.6 — and
still never collapses. Fans are audibly busier on both.
Note for anyone backporting it: the DTS patch must not travel alone. Patches
1–7 are the PDC irqchip secondary-mode/SCM work plus the revert of
602cb14e310a; without them GPIO wakeups still bypass PDC while the SoC ispermitted into a state where the GIC is powered down.
Also eliminated, each with evidence: PCIe/L1ss configuration (L1 substates are
supported and enabled at both ends of the NVMe link, and the qcom driver sets
broken_l1ss_resume), remote processors (adspandcdspboth running), andwake sources (disarming seventeen of them — USB, thermal sensors, remoteprocs,
WiFi, battery manager, UCSI — changed nothing).
So the remaining question is not what this machine is missing, but why a Yoga
Slim 7x is reported to suspend at ~0.4 W when the platform tracker says the
deepest state is not yet reached. That comparison is the only untried angle.
The two unmerged Linaro suspend fixes make this worse
Linaro's arm64-laptops tree, branch
arm64-laptops-v7.3-rc1-camss-v13, carriestwo suspend fixes that are in neither 7.2.6 nor 7.3-rc4:
5152af15soc: qcom: pmic_glink: Fix device access from worker during suspend4622de89usb: typec: ucsi: Schedule connector worker on freezable workqueueBoth are one-liners replacing
schedule_work()withqueue_work(system_freezable_wq, ...), so the workers cannot run while devicesare suspended. The first explains itself as a Type-C retimer being driven over
I2C while the I2C controller is down, "proven to be the case on the X Elite
boards". They address genuine correctness bugs.
Applied alone to 7.2.6 — a single-variable test, with the idle-state series
explicitly not applied — they roughly double suspend drain, from ~1.10 W to
~2.00 W over comparable 33–36 minute runs, with the fans audibly at full speed
throughout.
cxsdstayed at 0, so the SoC still never collapses; it simplyburns more while not collapsing.
A hypothesis, not established: freezable workqueues are frozen during suspend,
so deferring the
pmic_glinkaltmode worker may leave a Type-C/DisplayPortpath powered through the sleep.
One run per kernel. Worth knowing before adopting them on this hardware, and
worth a maintainer's attention if they head upstream.
Two things that mislead
a 3-minute sleep reads 2.19 W on a machine that measures 1.14 W over 36.
Compare only runs of similar, and preferably long, duration.
genpdidle_statescannot answer this. They count runtime idle and areblind to system suspend; every domain shows a few milliseconds across a
six-minute sleep, which means nothing. Use
qcom_stats./proc/interruptsacross all numeric fields. Thepmic_arbhwirq column gets counted as interrupts, which fabricates a storm that is not
there —
temp-alarmactually fires zero times. Sum only the per-CPU columns,of which there are
head -1 /proc/interrupts | wc -w.Unrelated but measurable: the shell polls for the power profile
Fixed upstream in Omarchy since this was measured: the battery module now
reads the property with
busctlinstead. Originally it ranpowerprofilesctl getevery 2 seconds byspawning a fresh Python interpreter
(
/usr/share/omarchy/shell/plugins/services/battery/Service.qml). That costs86 ms of CPU per invocation — 43,200 spawns and about 62 CPU-minutes per
day, a standing 4.3% of one core. The same query over D-Bus with
busctlcosts 2 ms; a
PropertiesChangedsubscription would cost nothing. Sincepower-profiles-daemonwas a no-op on this hardware, that was an hour of CPU aday spent polling a daemon that did nothing here.
Current configuration on this machine
What this laptop is actually running, as of 23 September 2026 — so the results
above can be reproduced, and so it is clear which fixes are local rather than
upstream.
7.2.7-2.3(held withIgnorePkg; adds the Linaropmic_glink/ucsifreezable-wq fixes, details, and QREF supplies from Ubuntu's X1 kernel, details; details), a local build of the Arch Linux ARMlinux-aarch64package plus the in-review camera series, a CAMSS data-lanes fix, the SCMI sustained-frequency fix, the 7.4pmdomain/cpuidle-pscibackport and the 7.3 PDC/deepest-idle-state series;CONFIG_QCOM_SPMI_ADC5_GEN3=mfor the board-thermistor ADC; since7.2.6-1.6alsoCONFIG_VIDEO_QCOM_IRIS=mandCONFIG_SM_VIDEOCC_8550=m(hardware video decode)/dev/video42viav4l2-relayd(1280×720 source,saturation=1.0 contrast=1.1 gamma=2.6);ov02e10.yamlwith Qualcomm's per-CCT CCMs (70 % blend); privacy LED linked in the DTB by a pacman hook (verified: lights while streaming)schedutilon all three clusters (policies 0, 4, 7), set viacpufreq.default_governor=schedutil; power-saver caps them at 2188.8 MHz (and the GPU at 687 MHz) viadell-7441-power-profiles.service(WantedBy=graphical.target)DeviceTreeAutolist; needsENABLE_UKI=yesin/etc/default/limine, otherwise kernel installs write a boot entry without a device tree; the ISO's quiet-boot flags must be re-added in/etc/limine-entry-tool.d/quiet-boot.conf;fw_devlink.sync_state=timeoutadded in/etc/limine-entry-tool.d/sync-state.confsync_state()(was ~1.01–1.07 W; baseline ~1.10 W); CDSP now sleeps; SS3 requested, but the SoC still never reaches Cx/DDR collapse; the ADSP wakes ~100×/s from its own firmware (every Linux client ruled out); unchanged withoutclk_ignore_unused pd_ignore_unused, which were then restored because removing them caused a frozen boot (details)cluster_cl5removed from the three cluster power domains by a pacman DTB hook (89-…), as in laptops-kernel5c3cf1033d(X1 DC ZVA reset erratum)test_resumehangs during the image write; Omarchy's swapfile andresume=left as installed0xB9= 1/0 at0x3b, 64-byte write as in Linaro'sdell-xps-ec) from a systemdsystem-shutdownhook and asleep.targetunit (dell-ec-standby-sleep.service, replacing thesystem-sleephook after systemd 262 started passing empty hook arguments, details), plus0xB9= 0 at boot (dell-ec-resume.service);i2c5kept at 100 kHz by a pacman hook;dell-ec-thermal-reporter.servicesends the board thermistors (SYS_THERMn → EC id n+1) every 0.5 s; ADC via a locally builtqcom-spmi-adc5-gen3module and DT overlay (hook88-…)Two board-specific device-tree fixes are applied automatically after every
kernel upgrade by the
dell-inspiron-7441-supportpackage, whose pacman hook(
85-dell-inspiron-7441-dtb.hook) runs before the initramfs/UKI is rebuilt:cpu@10300/cpu@20300status = "fail"Both are needed because
/boot/dtbs/qcom/*.dtbis owned by the kernel package,so a kernel upgrade replaces it. Each script is idempotent and explains its
reasoning in its header.
Kernel variants tested and rejected
These were built and measured on this machine, and are recorded so nobody
repeats them:
pmic_glink,ucsifreezable wq)7.2.7-2.3: 0.916 W, no cost; kept (details)status = "disabled"on the fused coresfail/fail-status = "fail"on the fused corespmdomain/cpuidle-pscibackportdomain_ss3entered at idle and in suspend, butcxsdstill 0; kept for now7.2.6-1.6)cluster_cl5(DTB hook)linux-qcom-x1e(7.2.7-2.2)cxsdstill 0; kept (details)Upstream status
Everything on this page that is not board-local. "Local" means it works here
but has not been proposed anywhere, which is a gap rather than a state to be
satisfied with.
CONFIG_VIDEO_OV02E107.2.7-1(PR closed)DevicePolicy=closedallow-list is Intel-IPU6-specific, so libcamera's software ISP cannot start under the service on any Qualcomm machineDmaBufAllocatorprefers the CMA heap over the system heap and exhausts small CMA poolsCONFIG_DRM_DISPLAY_DP_AUX_CHARDEV7.2.7-1(PR closed)dp_aux_backlightregisters withmax_brightness: 0Reported-byfrom this machinealsa-ucm-conflinux-firmwarecontains speaker tuning, on any machine95f827ceTwo of those are mine to finish rather than anyone else's to merge: the sound
channel-layout report, and a Tested-by for the camera DT series against v7
rather than the v6 I actually ran.
On backporting
95f827ceto a 7.2.x fork: it only toucheshamoa.dtsi, whichthis board includes, so it applies here directly. But its commit message is
explicit that PDC has to wake the SoC, because the GIC sits on Cx and is not
functional in the deep state, and it depends on the PDC irqchip secondary-mode
and SCM work that also reverts
602cb14e310a. In 7.2.6 that bypass is stillin place:
so a DTS-only backport would enable the deepest idle state while GPIO wakeups
still bypass PDC. The PDC series and the pinctrl revert belong with it.
For reference, this board's current idle states:
Cluster collapse is present; the SoC-deepest state is not.
Trying this on another Inspiron 7441
These commands inspect the system without installing anything:
To reproduce the probe capture above, boot the stock device tree with these temporary kernel command-line options and read the log afterwards:
Note that Omarchy boots a UKI and Limine supplies its own kernel command line, which overrides the one embedded in the image when Secure Boot is off — so setting it via
ukify --cmdlinealone has no effect. Set it on the entry inlimine.confinstead.Reading raw DPCD directly is not possible on the stock Arch Linux ARM kernel. The relevant option is off:
so there is no
/dev/drm_dp_aux*and no chardev module, and the dynamic-debug route above is the substitute on a stock kernel. Note the symbol isCONFIG_DRM_DISPLAY_DP_AUX_CHARDEV, not the olderCONFIG_DRM_DP_AUX_CHARDEV— the DP helpers now live underdrivers/gpu/drm/display/, alongsideCONFIG_DRM_DISPLAY_DP_AUX_BUSandCONFIG_DRM_DISPLAY_DP_HELPER, which are enabled.Enabling it is now proposed for ALARM in PKGBUILDs#2225. With a locally built kernel carrying that option, the internal eDP appears as
drm_dp_aux2(onaea0000.displayport-controller) and the full capability range can be read directly, rather than only the five bytes the driver happens to fetch:These 48 bytes match a capture taken independently on another Inspiron 7441.
Installation on this machine originally needed platform-specific package work and a local
platforms.jsonworkaround; see #7739 for that account and #11823 for current installer state, rather than assuming either still applies.Keep a known-good boot entry and recovery media before changing the device tree. Do not copy this machine's device tree to another laptop model.
Next validation steps
Test withoutSuspend unchanged (~0.90 W,clk_ignore_unused pd_ignore_unused.cxsdstill 0), and one boot in five froze with a garbled screen (display clocks/GDSC switched off before themsmmodule loads), so they are required and have been restored (details). Remaining suspect: the ADSP firmware's ~100 Hz tick.Test hibernation.Tested: freeze/thaw passes, the image write hangs, so it's left disabled (details). Still open: narrowing it down withpm_test=platform/processors/coreand a smallerimage_size.Test external display and USB-C alt-mode video.HDMI via a USB-C adapter works (tested with an Acer XGA projector, extended desktop). Still untested: native DisplayPort monitors, high-resolution/high-refresh displays, and the second USB-C port.Measure the actual PWM period for this panel so the backlight fix can go upstream with a correct value rather than the T14s one.Raised from the inherited 234 Hz to 2 kHz (500000ns), the valuex1p42100-lenovo-thinkbook-16uses on the same PMIC. Still not a measurement of this panel, but no longer a value chosen for different hardware. A proper measurement would still be worth having.x1e80100-dell-latitude-7455andx1e80100-dell-xps13-9345share the backlight problem — their device trees are in an identical configuration.Ask ALARM to enableBoth submitted: PKGBUILDs#2225 and PKGBUILDs#2226, awaiting review. Both options are now enabled in ALARM'sCONFIG_VIDEO_OV02E10for the camera, alongsideCONFIG_DRM_DISPLAY_DP_AUX_CHARDEVfor eDP debugging.7.2.7-1config.camss/cci/csiphynodes behind the Yoga Slim 7x's working camera are SoC-level and reusable here, or entangled with board-specific wiring. This determines whether the Dell camera is a porting job or an enablement project.Get the raw camera pipeline usable by ordinary applications, which needs libcamera's software ISP and a V4L2 bridge— done, see Webcam. Still open: whether the Latitude 7455, which sharesx1-dell-thena.dtsi, also works.Report upstream thatFiled as vicamo/v4l2-relayd#3. The allow-list is upstream's, not Omarchy packaging — the installed unit matchesv4l2-relayd'sDevicePolicy=closedallow-list is Intel-IPU6-specific, so libcamera's software ISP cannot start under the service on any Qualcomm machine.mainexactly.Raise with libcamera thatFiled as libcamera#352, with three suggested remedies led by falling back to the next provider when allocation fails rather than only when open fails.DmaBufAllocatorprobeslinux,cmabeforesystemunconditionally, which misbehaves on boards with a small CMA pool shared with the display.alsa-ucm-conf. The four WSA884x channels alternate sides (ch0/ch2 left, ch1/ch3 right) and no current mechanism expresses that, so PipeWire reads a two-way stereo pair as 4.0 surround.linux-firmwarecontains any, on any machine, so this is measurement work rather than a code change, and it would benefit every Snapdragon X laptop rather than only this one.Please report the exact model, BIOS, kernel and package versions, and whether you tested a live or installed boot. Mark untested features as untested rather than assuming they match this machine.
All reactions