Brightness bug in ubuntu on a dell laptop

# Intel Backlight Not Working on Dell Inspiron 15 (3511) — Ubuntu Linux (Windows Works Fine)

## Hardware
- **Lapmargin: 0; ;margin: 0;">## The Problem
The physical brightness keys are detected correctly — the on-screen GUI slider moves up and down as expected — but the actual screen backlight never changes. It stays fixed at one brightness level no matter what.

**Windows works perfectly on the same machine (dual boot).** Brightness control functions normally there, which confirms the panel, backlight hardware, and physical keyboard hotkeys are all working. This points to the failure being a communication problem specifically between the Linux kernel (`i915`), and Dell's EC/ACPI firmware — not a hardware fault.

## What We've Proven
Writing directly to the hardware register confirms the driver is issuing commands, but the panel ignores them:

```
echo 50 | sudo tee /sys/class/backlight/intel_backlight/brightness
```

The file updates successfully and `cat`ing it back shows the new value, but the physical screen brightness does not change. So this isn't a missing-GUI or broken-hotkey-daemon issue — `i915` is sending the command, but the embedded controller (EC) or PWM/panel line is not acting on it under Linux.

## Troubleshooting Steps Attempted (none have worked)

**1. Kernel parameter tweaks (`/etc/default/grub`, `GRUB_CMDLINE_LINUX_DEFAULT`)**
- `acpi_backlight=native` — forces Intel direct control. *Failed.*
- `acpi_backlight=vendor` — forces Dell's proprietary firmware path; `dell_wmi` and `dell_laptop` modules loaded. *Failed.*
- `acpi_backlight=video` — generic ACPI video driver. *Failed.*
- `acpi_backlight=none` — stripped ACPI backlight entirely; this broke the GUI slider and hotkey detection completely, so it was reverted.

**2. Intel graphics driver tweaks**
- `i915.enable_dpcd_backlight=1` — force DisplayPort Configuration Data (DPCD/AUX) backlight protocol in case the panel uses eDP AUX instead of PWM. *Failed.*
- `i915.enable_psr=0` — disabled Panel Self-Refresh in case it was freezing backlight registers. *Failed.*
- Blacklisted the `xe` module in `/etc/modprobe.d/` and rebuilt `initramfs` to guarantee `i915` had exclusive control (both `i915` and `xe` were showing as loaded). *Failed.*

**3. Hardware / power state resets**
- Disabled Windows Fast Startup and hibernation, to rule out Windows locking ACPI power states before booting Ubuntu. *Failed.*
- Full motherboard power drain (30-second power button hold, unplugged) to clear a potentially stuck Dell Embedded Controller. *Failed.*

**4. Software-level workaround**
- Installed the **Soft Brightness Plus** GNOME extension to bypass the hardware entirely and dim via gamma/software instead. With default settings, it did not visibly dim the screen.

**5. Deeper diagnosis (ACPI table trace + SMI verification)**

Dumped and disassembled the DSDT to trace the actual brightness control path:
```
sudo acpidump -o acpi.dat && acpixtract -a acpi.dat && iasl -d dsdt.dat
```

Findings:
- `_BCM` (Set Brightness) does **not** talk to any graphics register. It packs the brightness value into a buffer and calls `GENS(0x09, BRT3, SizeOf(BRT3))`.
- Since the argument is a Buffer, `GENS` routes to `SMBF`, which writes the value into a memory-mapped region at `SMBA = 0x64513000`, then calls `ASMI()`.
- `ASMI()` writes `0xE0` to I/O port `0xB2` — a genuine **System Management Interrupt (SMI)** trigger. This hands control to the BIOS's SMM (System Management Mode) firmware, which is opaque/binary and identical for both Windows and Linux, since it's firmware, not OS-level code.
- Confirmed with `ls /sys/class/backlight/` that only `intel_backlight` was present (native `i915` PWM/DPCD register control), meaning the SMI-based ACPI path above was never actually being exercised by default. Adding `acpi_backlight=video` to GRUB and rebooting exposed a second device, `acpi_video0`, which **does** route through the `_BCM`/`_BQC`/SMI path above. Writing to it directly (`echo 3 | sudo tee /sys/class/backlight/acpi_video0/brightness`) still did not change the physical screen.
- **Verified the SMI is actually firing** using the CPU's `IA32_SMI_COUNT` MSR (register `0x34`, readable via `rdmsr -p 0 0x34` from `msr-tools`). The count incremented by exactly 1 on every single write to `acpi_video0/brightness` (`0x9f0 → 0x9f1 → 0x9f2`), confirming the ACPI method, the SMI trigger, and the BIOS's SMM handler all execute correctly end-to-end. The backlight still does not change.

**Conclusion: this points to a firmware (BIOS/SMM) bug, not a Linux kernel, driver, or configuration issue.** The full software/ACPI chain — `_BCM` → `GENS` → `SMBF` → `ASMI` → SMI → SMM handler — executes exactly as designed and is confirmed via hardware MSU counter to reach Dell's BIOS firmware code. Whatever the SMM handler does once triggered is not something any OS-side driver, kernel parameter, or workaround can influence. Windows working does not contradict this: Windows very likely uses a separate, non-ACPI path (e.g. Intel's own graphics driver brightness interface) rather than this SMI-based one, so it may simply never exercise this particular (broken) firmware code.

## Current Status / Ask
- Checked BIOS version via `dmidecode -s bios-version`; comparing against Dell's latest available BIOS for this service tag, since this class of bug (SMM handler accepting the correct interrupt but not acting on it) is exactly what firmware updates are typically issued to fix.
- If already on the latest BIOS: filing this with Dell support and/or the kernel/freedesktop ACPI bug trackers, since the exact AML trace and SMI-counter verification above should save whoever picks it up a lot of diagnostic time.
- Open to hearing from anyone with the same laptop (or Tiger Lake Dell Inspiron/Latitude models generally) who has hit this same `_BCM`-via-SMI dead end, especially if a specific BIOS version resolved it.